'Twas brillig, and pl bossart at 17/01/11 20:24 did gyre and gimble: > Thanks Colin for reading my prose.
No worries. I'm just sorry it took so long to reply. I had quite a few messages on this list marked as "todo" and I've only just caught up on my emails after being very lazy over the holidays :) >>> - 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. Don't worry. All I was really trying to say is that the kind of people who currently moan about us not supporting dynamic adjustment of sample rates, are the same people that want us to support their specific h/w to the fullest possible extent, regardless of the technical or operational issues we mention. Those people probably wont be satisfied by a semi-automatic switch as you describe and will still want "more"! That's not to say I don't think it's a good ideas because, like Arun, I do :) >> 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... Yeah, I appreciate the IDLE case would require more work to force the reinit, especially if you still get issues when SUSPENDED on some h/w! >> 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? Well I guess I was thinking about this guide from MS which states what they do. http://msdn.microsoft.com/en-us/library/ff537756%28v=VS.85%29.aspx All the like-rated stuff is mixed, then SRC is done if needed. I believe at the moment we SRC all streams, then mix, but the above system is a little more involved. People have requested h/w mixing before tho', but I'm not sure if that's simply because their h/w supports it and they want to offload to it, or whether they had real, practical benefits. The only practical benefit of h/w mixing I can think of is to allow for separate sample rates to be pushed to the card simultaneously and let it mix them (with SRC in h/w) as appropriate. That way we don't do any SRC in software but support several rates. I'm really not sure what h/w supports this or (as I said previously) if this is such a niche case as to not worry about. You probably have a much better idea of this than me practically speaking! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
