[pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate

[pl bossart]

Thanks Colin for reading my prose.

> Yeah, doing it server wide makes no sense IMO. The default-sample-rate
> configure option predates our mixer profile logic and really (IMO)
> somehow be wrapped up into card profiles or sink/source ports anyway,
> but I digress.

That's actually a good point. I just took the existing
default-sample-rate and built on it, but yes there's no reason to have
a server default value. You could have HDMI at 192kHz, no reason to
prevent higher frequencies if they were available.

>> - To avoid quality issues, I limited the sinks to two frequencies,
>> 44.1 or 48kHz. If we allowed for lower sampling rates, it'd be a
>> problem if additional sink-inputs/source-outputs are created at a
>> later stage with a higher sampling rate. This means that for a phone
>> call or voice memo you would still see a resampling, but it should be
>> lighter with integer instead of fractional ratios.
>
> While I see the logic behind it, it'll likely not placate all those
> people who want dynamic rate switching. Perhaps this will need to be
> extended at some point but perhaps it's a sensible starting off point.
> I'm thinking more of even larger frequencies rather than lower ones
> (although the practical usefulness could obviously be debated endlessly)

Humm, I didn't follow your thinking here.

>> - the sinks/sources only get suspended after a 5s timeout. This seems
>> too high for sinks/sources that can be reconfigured quickly. It may
>> make sense to have different values for the timeout, and make them
>> dependent on the configuration latency.
>
> Or perhaps the "OK to change rate" logic could work when the sink is
> either IDLE || SUSPENDED ? That way the suspend timeout wouldn't really
> matter. Just a thought.

I have more work to do on IDLE. This typically happens when the
sink-input is corked, so you could add an SRC if for some reason the
rate was changed. Even in the SUSPENDED case my USB headset seems to
complain...

> One thing I think would be very interesting here would be cards that
> support hardware mixing.
>
> With these cards, would it be possible to open a stream for each of the
> different rates we want to use? Then when we deal with the mixing, we
> mix all the like-rated inputs together and send those separately to
> their matched device-stream?
>
> That is likely the best use of such hardware and the best implementation
> of support for multiple rates, but it's possibly not worth thinking
> about immediately due to the fact that this h/w is likely in a minority.

I can see cases where you have 1 compressed stream and 1 PCM, and you
mix the two in hardware, but I am having a really hard time finding a
use case where you would have multiple (more than 2) PCM streams at
different rates. Maybe automotive cases, where the infotainment unit
might send multiple streams to a head unit were the mixing/routing is
actually done? Did anyone request hardware mixing on the mailing list?
-Pierre