[pulseaudio-discuss] Progress of 'dynamic default sink' or 'device preference list'?
Hi all, Now that 0.9.22 is finally out, I'm wondering what happened to what Colin mentioned some time back about 'device preferences'. As I understood at the time, assuming 3 possible sound devices (which may or may not be plugged in):- 1. New streams would be automatically sent to the highest priority device on starting 2. Streams which have been manually moved would stay where they've been moved to. 3. When another device which has a higher priority is plugged in, all streams (except for those in 2.) are moved to it. This scheme was mentioned in preference to a generic "move all sound to latest plugged-in-device" scheme, I believe. Are there any plans in this direction? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Supporting hardware resampling
heory you'd want to group all the same-freq data together, mix it >> and then pass it to the sink which would use the DSP to do the >> resampling needed, which isn't really something supported right now in >> the PA architecture AFAIK. > > With the links you've got to most DSPs you don't actually need to do the > pre-mixing - the DSP can do the mixing too. The DSP I have is plenty capable, it could do all the mixing. The problem I'm having is I'm still a Pulse Audio module newbie, and from what I've seen (please PLEASE tell me how to do it right if I'm wrong) a sink can only advertise one sample rate it accepts, any sink input connected to it will resample before arriving. Colin's musing seem to agree with this too, as he mentions combining identical sample rates. Luckily muxing is cheap, at least when identical rates are coming in it's little more than an addition. >> The trick comes from knowing the h/w can do this. I guess one way of >> working would be to change things so that each sink can actually open >> the h/w multiple times for different sample rates if it supports h/w >> mixing and simply route the audio to the appropriate connection, all the >> while maintaining a single sink "view" to all things higher up. > > For things like the emu10k based cards simply opening the PCM until you > get an error should do the job here. Yeah, I can open some obscene amount of PCM paths into the DSP, and my original goal was to open one per input (and hopefully recycle cleanly too), but it sounds like I'll have to open one per sample format, mux, and then pass to the DSP on render for resampling and muxing with others. >> It's likely something that will be attached in some way to the UCM work >> in alsa, so that this kind of thing is only configured when we are told >> it will work. > > This would work for OMAP. The other thing that Pulse should be able to > use eventually is Laurent Pinchard's media controller work which will > allow Pulse to discover the audio routing within the device. Probably > that will cover most of the PC cases. All good future improvements, maybe some day I can take advantage. For now it looks like I'm left to pioneer some fairly custom solution. One module to load (if necessary) a matching sink and route to it, and one module to actually do the DSP rendering. Thanks for the discussions so far guys! -- Wade ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Supporting hardware resampling
On Tue, Nov 30, 2010 at 12:44:45PM +, Colin Guthrie wrote: > In theory you'd want to group all the same-freq data together, mix it > and then pass it to the sink which would use the DSP to do the > resampling needed, which isn't really something supported right now in > the PA architecture AFAIK. With the links you've got to most DSPs you don't actually need to do the pre-mixing - the DSP can do the mixing too. > The trick comes from knowing the h/w can do this. I guess one way of > working would be to change things so that each sink can actually open > the h/w multiple times for different sample rates if it supports h/w > mixing and simply route the audio to the appropriate connection, all the > while maintaining a single sink "view" to all things higher up. For things like the emu10k based cards simply opening the PCM until you get an error should do the job here. > It's likely something that will be attached in some way to the UCM work > in alsa, so that this kind of thing is only configured when we are told > it will work. This would work for OMAP. The other thing that Pulse should be able to use eventually is Laurent Pinchard's media controller work which will allow Pulse to discover the audio routing within the device. Probably that will cover most of the PC cases. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Supporting hardware resampling
'Twas brillig, and Wade Brown at 30/11/10 02:57 did gyre and gimble: > Pierre, > >> Default PulseAudio behavior is to mix in software. If you wanted to >> mix in hardware, you could highjack the passthrough work I've been >> doing for AC3. Essentially one device for sw mix, and a number of hw >> devices with no processing in PulseAudio. Still fairly hairy stuff at >> this point since you need to tag each stream as passthrough or not, >> and route explicitely to a specific device for hw or sw mixing. You >> would also need to load these devices by hand in the default.pa >> configuration or use a specific profile for your hardware. >> -Pierre > > I assume you're talking about the submitted patch here: > http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg07283.html > > It seems like I could work with this, but it may not be pleasant. I > haven't dug too deep yet, but if the nature of Pulse Audio is to only > deliver one stream to any given sink I'm probably out of luck. > Creating several would be easy, but routing streams intelligently does > not look look so friendly. I don't suppose anybody has cobbled > together some sort of round robin allocator. For passthrough stuff, yes, it can only take one stream at a time, but for normal audio there can be multiple streams which are all mixed and resampled (or resampled and then mixed, I'm not 100% sure which: the windows policy is to mix first AFAICT, http://msdn.microsoft.com/en-us/library/ff537756%28v=VS.85%29.aspx but would need to look and see what we do as i don't know that bit of the code too well). In theory you'd want to group all the same-freq data together, mix it and then pass it to the sink which would use the DSP to do the resampling needed, which isn't really something supported right now in the PA architecture AFAIK. The trick comes from knowing the h/w can do this. I guess one way of working would be to change things so that each sink can actually open the h/w multiple times for different sample rates if it supports h/w mixing and simply route the audio to the appropriate connection, all the while maintaining a single sink "view" to all things higher up. This would require a reasonable amount of rework to do things correctly however (and I'm not even sure that it's the right approach anyway). It's likely something that will be attached in some way to the UCM work in alsa, so that this kind of thing is only configured when we are told it will work. Just some idle musings on the topic that may, or may not be ill-informed! 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
Re: [pulseaudio-discuss] [PATCH] alsa-sink: take base volume into account when applying hw volume
Any comments on this one Jyri? It seems add code to sink_write_volume_cb() to mirror the normal method sink_set_volume_cb() so looks OK to me but not followed the path through to see if this is supposed to be factored in already in some other way... Your thoughts would be appreciated. Col 'Twas brillig, and Juho Hämäläinen at 25/11/10 13:15 did gyre and gimble: > Currently if sink base volume differs from 0dB and sync-volume is used, > wrong volume values are written to hw. This patch fixes that. > > > Signed-off-by: Juho Hämäläinen > --- > src/modules/alsa/alsa-sink.c | 10 -- > 1 files changed, 8 insertions(+), 2 deletions(-) > > > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@mail.0pointer.de > https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss -- 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
