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
