Re: [pulseaudio-discuss] Is it possible to compress pulseaudio's network streams?
There are currently no plans and no active development on compressed network streams for PulseAudio. That said, it would be nice to have some day. It seems that the consensus is that the CELT codec would be best suited for this, because of it's tight control over latency. When streaming audio (especially over wifi) latency and jitter are much more of a concern than bandwidth. There is certainly some room for improvement there, even without adding a crompressed stream format. Maarten 2011/5/10 Aitor Pazos : > Dear list, > I've been using Pulseaudio over the network for a while. When my laptop is > docked it works pretty well through the wired connection, but when I go > wireless sound gets choppy. This situation makes the whole network > functionality almost non-sense for me as I could attach my usb sound card > directly to my dock station (with 5.1 speakers). Checking the traffic I get an > around 4mb/s sustained flow which I guess is too high for my unreliable > wireless network. > I've googled quite a lot and I haven't found any real effective solution to > this issue. I guess the better solution would be to compress these streams in > order to reduce bandwidth requirements. Is it possible to do this in > pulseaudio. Are there any plans of implementing some solution for this > situation? Which are the most important parameters I should try to tune apart > from "default-fragments" and "default-fragment-size-msec"? > > Thank you very much, > Aitor Pazos ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] echo-cancel: Handle alignment requirement manually
'Twas brillig, and Arun Raghavan at 09/05/11 09:10 did gyre and gimble: > PA_ALIGNED can't always guarantee that the alignment we want (the GCC > man page suggests that the linker might not be able to meet the > alignment requirements we desire). Instead, we now allocate some extra > memory and guaratee that the alignment we require is met. Looks fine (but sad that it's not easier). Pushed. 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] echo-cancel: Remove unnecessary noalign attribute
'Twas brillig, and Arun Raghavan at 10/05/11 09:03 did gyre and gimble: > This was just introduced for debugging and should not have been in the > final commit. Won't make a difference at the moment since this function > is used as a pointer, but removing this in case we change this in the > future. Thanks. 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] [PATCHv3 0/4] Read and store UCM data as proplist
'Twas brillig, and Jorge Eduardo Candelaria at 10/05/11 21:29 did gyre and gimble: > This is the third version of the Pulseaudio and UCM integration. > > This set of patches cover adding ucm data to proplist, adding a ucm API > to get and set data to proplist, and lets module-alsa-card scan ucm data > when the card is probed. > > Another set of patches dealing with jack module detection will be sent > separately. Thanks for this. I believe David will be helping review this stuff, but is currently at UDS. WRT the jack detection, I think we all agreed that it needs to be handled more internally in the alsa code rather than separated as a module. I'm not 100% sure of the finer details but I know David had ideas here too. We basically need to match up the jack stuff with the appropriate sink/source device on the system and then develop a way to automatically change sink/source ports accordingly (it may also require that we change the card profile too - e.g. change from a 5.1 profile to a stereo profile when plugging in stereo headphones). I'm not sure how to detect multiple jacks - e.g. if you plug in 3 jacks to do 5.1 output, should 5.1 be handled automatically? Anyway, all the jack detection stuff should be totally separate from UCM stuff and could in theory be committed first. UCM should just hook into port/profile changes for pushing new configs up to ucm and set the appropriate verb+modifiers on the device. (disclaimer, my UCM foo is still not awesome, but I think this is all the consensus we reached on the matter!). 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] module combine not respecting requested latencies
Hello, Maarten Bosmans wrote: Please have another look at your patch. This is setting BLOCK_USEC to 10 seconds, not ms. Moreover, I don't think BLOCK_USEC is related in any way to the default adjust_time, so if changing BLOCK_USEC, better set it to some other hardcoded value, to avoid the suggestion that it has anything to do with the adjust_time. Woops my bad, in my patch I just set it to 0, you're right that patch is wrong, my patch was to simply change pa_sink_input_set_requested_latency(o->sink_input, BLOCK_USEC); to: pa_sink_input_set_requested_latency(o->sink_input, 0); Which sets it to minimum latency possible, however I can imagine in some cases you want to allow bigger latencies, so I doubt that is the complete solution, the total minimum latency should probably be the maximum of the minimum latency of each individual sink being used, while the real latency set should be set to minimum tolerable, but that module confuses me because it's both an output and an input, so I don't see how it should be done. Cheers, Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCHv3 0/4] Read and store UCM data as proplist
On May 11, 2011, at 6:43 AM, Colin Guthrie wrote: > 'Twas brillig, and Jorge Eduardo Candelaria at 10/05/11 21:29 did gyre > and gimble: >> This is the third version of the Pulseaudio and UCM integration. >> >> This set of patches cover adding ucm data to proplist, adding a ucm API >> to get and set data to proplist, and lets module-alsa-card scan ucm data >> when the card is probed. >> >> Another set of patches dealing with jack module detection will be sent >> separately. > > Thanks for this. I believe David will be helping review this stuff, but > is currently at UDS. > > WRT the jack detection, I think we all agreed that it needs to be > handled more internally in the alsa code rather than separated as a module. > > I'm not 100% sure of the finer details but I know David had ideas here too. > > We basically need to match up the jack stuff with the appropriate > sink/source device on the system and then develop a way to automatically > change sink/source ports accordingly (it may also require that we change > the card profile too - e.g. change from a 5.1 profile to a stereo > profile when plugging in stereo headphones). Unfortunately, the jack matching to source is not that clever yet in the drivers. :( There is no way to really be sure that Jack X matches stream Y. This information should be available in the future though (for ASoC drivers at least) when the DAPM graphs are exported. In the mean time all we can do is know whether a jack is inserted or removed for a particular sound card. > > I'm not sure how to detect multiple jacks - e.g. if you plug in 3 jacks > to do 5.1 output, should 5.1 be handled automatically? Again, this is something that requires better driver and core alsa support. > > Anyway, all the jack detection stuff should be totally separate from UCM > stuff and could in theory be committed first. UCM should just hook into > port/profile changes for pushing new configs up to ucm and set the > appropriate verb+modifiers on the device. Ok, I'll copy the jack code we have into module-alsa-card. This will allow for simple jack removal/insertion events to be propagated to pulseaudio. We won't be able to do the complicated stuff mentioned above, but should at least be able to do simple speaker/headphone switching. > > (disclaimer, my UCM foo is still not awesome, but I think this is all > the consensus we reached on the matter!). > > 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCHv3 0/4] Read and store UCM data as proplist
'Twas brillig, and Jorge Eduardo Candelaria at 11/05/11 19:56 did gyre and gimble: > > On May 11, 2011, at 6:43 AM, Colin Guthrie wrote: > >> 'Twas brillig, and Jorge Eduardo Candelaria at 10/05/11 21:29 did >> gyre and gimble: >>> This is the third version of the Pulseaudio and UCM integration. >>> >>> >>> This set of patches cover adding ucm data to proplist, adding a >>> ucm API to get and set data to proplist, and lets >>> module-alsa-card scan ucm data when the card is probed. >>> >>> Another set of patches dealing with jack module detection will >>> be sent separately. >> >> Thanks for this. I believe David will be helping review this >> stuff, but is currently at UDS. >> >> WRT the jack detection, I think we all agreed that it needs to be >> handled more internally in the alsa code rather than separated as >> a module. >> >> I'm not 100% sure of the finer details but I know David had ideas >> here too. >> >> We basically need to match up the jack stuff with the appropriate >> sink/source device on the system and then develop a way to >> automatically change sink/source ports accordingly (it may also >> require that we change the card profile too - e.g. change from a >> 5.1 profile to a stereo profile when plugging in stereo >> headphones). > > Unfortunately, the jack matching to source is not that clever yet in > the drivers. :( There is no way to really be sure that Jack X > matches stream Y. This information should be available in the future > though (for ASoC drivers at least) when the DAPM graphs are exported. > In the mean time all we can do is know whether a jack is inserted or > removed for a particular sound card. I thought it reported some fairly useful names I'm sure David had some way to see some degree of info. For example on my machine: [root@jimmy ~]# cat /proc/asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xefebc000 irq 43 [root@jimmy ~]# evtest /dev/input/event7 Input driver version is 1.0.1 Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0 Input device name: "HDA Intel Mic at Ext Right Jack" Supported events: Event type 0 (Sync) Event type 5 (?) Event code 4 (?) Testing ... (interrupt to exit) So the string "HDA Intel" is present in both which we should be able to match up. >> I'm not sure how to detect multiple jacks - e.g. if you plug in 3 >> jacks to do 5.1 output, should 5.1 be handled automatically? > > Again, this is something that requires better driver and core alsa > support. Well not sure. I'd expect the different jacks to have different /dev/input/event* inputs with different jack names on them, so we should (in theory) be able to match that up no? >> Anyway, all the jack detection stuff should be totally separate >> from UCM stuff and could in theory be committed first. UCM should >> just hook into port/profile changes for pushing new configs up to >> ucm and set the appropriate verb+modifiers on the device. > > Ok, I'll copy the jack code we have into module-alsa-card. This will > allow for simple jack removal/insertion events to be propagated to > pulseaudio. We won't be able to do the complicated stuff mentioned > above, but should at least be able to do simple speaker/headphone > switching. Cool. Like I say it's probably worth chatting with David about it before coding too much, but I'm not sure how contactable he is due to UDS focus right now. It's not possible to do anything with jack detect unless we can match up the events with the device. If we can't do that, then we're stuck (e.g. imagine if the user has two sound cards) so I hope what I wrote above is indeed true! Cheers 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
