Re: [pulseaudio-discuss] review+pull-request: Passthrough support
'Twas brillig, and Arun Raghavan at 15/05/11 05:41 did gyre and gimble: On Tue, 2011-05-03 at 09:25 +0100, Colin Guthrie wrote: 'Twas brillig, and Arun Raghavan at 02/05/11 07:49 did gyre and gimble: In e193c2bf55326a48e2297bcacadc9d1848a40d7d and 948d0f19bef353208ffb5b1b8c520b6b489b94a6 Can you make sure that pactl and pacmd stay as in-sync as possible? I held off because I thought that pacmd was going to be dropped before too long. Is this not the case? Sink port information seems to have not been added, I'll sync that as well if required. Hmm, not sure. Ideally I'd prefer to just have one tool and only add to pacmd the things that cannot easily be done via the protocol, but I'm not sure of the overall strategy. I'll add this to the discussion points for Saturday's chat. Was this discussed? Any news? Sorry, I've not been awesome at writing up my notes. Am going to attempt to clear the decks today :D So pacmd is staying. It should be considered a debug tool however and pactl should be used for 99% of user interaction. For that reason, pacmd output can change more readily (i.e. the formatting can be adapted as/when needed), but pactl output is slightly more fixed due to people perhaps parsing it in scripts. In bb7cc499f1815de1c90b0ef1850152224df96ff9 I don't see why this asserts in the current form nor what has actually changed. It should not assert since we want to gracefully fail (that is the original code should not have been an assert). I still don't see any asserts in the original code. The only difference I can see is that a pa_log_debug() is not printed... (the log message says the word Assertion but it doesn't actually assert AFAICT...) This might be intended (i.e. don't print the log message), but if that's the case the commit message is still wrong to mention asserts... Ah, I see what you mean. Commit message amended. Cool. General Question: Has this broken tunnels? (we manage to do this quite often with stream protocol changes... Indeed, it does. I've put fixing this on my TODO list. Will try to get to it soon. Cool, thanks :) Done and pushed to my tree. :) Awesome. I'll merge it today most likely. Further fixes can be done on master with wider testing :) 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
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
On Tue, 2011-05-03 at 09:25 +0100, Colin Guthrie wrote: 'Twas brillig, and Arun Raghavan at 02/05/11 07:49 did gyre and gimble: In e193c2bf55326a48e2297bcacadc9d1848a40d7d and 948d0f19bef353208ffb5b1b8c520b6b489b94a6 Can you make sure that pactl and pacmd stay as in-sync as possible? I held off because I thought that pacmd was going to be dropped before too long. Is this not the case? Sink port information seems to have not been added, I'll sync that as well if required. Hmm, not sure. Ideally I'd prefer to just have one tool and only add to pacmd the things that cannot easily be done via the protocol, but I'm not sure of the overall strategy. I'll add this to the discussion points for Saturday's chat. Was this discussed? Any news? In bb7cc499f1815de1c90b0ef1850152224df96ff9 I don't see why this asserts in the current form nor what has actually changed. It should not assert since we want to gracefully fail (that is the original code should not have been an assert). I still don't see any asserts in the original code. The only difference I can see is that a pa_log_debug() is not printed... (the log message says the word Assertion but it doesn't actually assert AFAICT...) This might be intended (i.e. don't print the log message), but if that's the case the commit message is still wrong to mention asserts... Ah, I see what you mean. Commit message amended. General Question: Has this broken tunnels? (we manage to do this quite often with stream protocol changes... Indeed, it does. I've put fixing this on my TODO list. Will try to get to it soon. Cool, thanks :) Done and pushed to my tree. :) Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
'Twas brillig, and Arun Raghavan at 02/05/11 07:49 did gyre and gimble: In e193c2bf55326a48e2297bcacadc9d1848a40d7d and 948d0f19bef353208ffb5b1b8c520b6b489b94a6 Can you make sure that pactl and pacmd stay as in-sync as possible? I held off because I thought that pacmd was going to be dropped before too long. Is this not the case? Sink port information seems to have not been added, I'll sync that as well if required. Hmm, not sure. Ideally I'd prefer to just have one tool and only add to pacmd the things that cannot easily be done via the protocol, but I'm not sure of the overall strategy. I'll add this to the discussion points for Saturday's chat. In bb7cc499f1815de1c90b0ef1850152224df96ff9 I don't see why this asserts in the current form nor what has actually changed. It should not assert since we want to gracefully fail (that is the original code should not have been an assert). I still don't see any asserts in the original code. The only difference I can see is that a pa_log_debug() is not printed... (the log message says the word Assertion but it doesn't actually assert AFAICT...) This might be intended (i.e. don't print the log message), but if that's the case the commit message is still wrong to mention asserts... General Question: Has this broken tunnels? (we manage to do this quite often with stream protocol changes... Indeed, it does. I've put fixing this on my TODO list. Will try to get to it soon. Cool, 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] review+pull-request: Passthrough support
'Twas brillig, and Arun Raghavan at 13/04/11 13:53 did gyre and gimble: Hey folks, My passthrough work is now at a point where I think it's good to pull to master. All the core code for clients to signal that they are providing a compressed format, and sinks to signal what formats they support is there. The API is essentially the same as discussed earlier on-list, with some small tweaks along the way as necessary. Still pending are proper detection/signalling of available formats on ALSA devices is to be done (Colin's looking at some of the plumbing for S/PDIF, and HDMI ELD/EDID-based lookups are something that we need as well), and better handling of monitors (we suspend them for now, which works), and volumes (Tanu's got some on-going work on this). NOTE: given the above about ALSA, topmost patch should probably not be pulled, but is handy to have for testing. In addition to the passthrough branch, there is a passthrough-bt branch which has changes to the bluetooth sink to support streaming MP3 to headsets that support it. This also needs some work before being ready to pull. The changes needed to actually use this in GStreamer are also done, but not upstream yet. I need to do some rebasing to make this stuff good to push out, so details on this in a following mail. Comments, feedback will be very much appreciated. :) are available in the git repository at: git://git.collabora.co.uk/git/user/arun/pulseaudio.git passthrough Not tried the code (yet), but will do this week. I have reviewed all the code yet! But I did review all the commits! Most of my comments are trivial tho' (and some are already fixed it seems!) In 4a839b3767ae5571c69bd591b5a59d7307cba13e pa_format_info_to_sample_spec() and pa_format_info_to_sample_spec_fake() some pa_assert's should pa_assert_se's. (Update: I think these are all rectified in 38309769c5a630ee78ae73be6fb407624c1509fc) In 7e8b65bc4f490628f20ab420a6c80bfa3a760bc6 Shouldn't pa_create_stream_callback() call pa_tagstruct_get_format_info() up to n_format times and only bail if all are invalid? Minor typo: Send back the format me negotiated s/me/we/ Minor typo: We're working not working with the extended API s/working not/not/ pa_sink_input_new_data_set_formats(): Please drop the last else and just put the return TRUE as the last statement. It's trivial but I believe this looks neater to always have a return at the top level of the function. In d885a39b9f1085e759ad69afcc939caffb1fbc5a Minor typo: but this is can very well be incorrect s/this is/this/ In e193c2bf55326a48e2297bcacadc9d1848a40d7d and 948d0f19bef353208ffb5b1b8c520b6b489b94a6 Can you make sure that pactl and pacmd stay as in-sync as possible? In bb7cc499f1815de1c90b0ef1850152224df96ff9 I don't see why this asserts in the current form nor what has actually changed. In 9d5e8867066e392fa40add0f0380374131dfc2de Minor: pa_streq has a space before the (. In d9e0f3bc0286249ced30a4728e4467f7a46f37af Already merged in 837e0a960630251ce30c124da5e65079b748d978 Should we rebase before merge or is it wise to keep your tree as is for ease of working with existing checkouts? General Question: Has this broken tunnels? (we manage to do this quite often with stream protocol changes... That is all! Take care 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] review+pull-request: Passthrough support
Somehow we need to find a way to set this AES0 byte when opening the iec958 or hdmi device in the passthrough code, and reset it back to 0x04 for PCM playback (should be fairly easy to do by looking at the code of iecset in alsa-utils). Beats me why this was not needed for plain ac3, but setting the audio bit is actually the correct thing to do. If my reading is correct, this is something we should do for all formats anyway? Yes. The C bits are usually ignored by the receiver since a lot of sources don't configure them well. But it turns out that in this case setting the non-audio bit is a mandatory setting. Is the ALSA device correctly being configured to 192 kHz? I will have to recheck for these two cases. I guess it is since I can see the D+ logo, but let me confirm for these two cases. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
Yes. The C bits are usually ignored by the receiver since a lot of sources don't configure them well. But it turns out that in this case setting the non-audio bit is a mandatory setting. I tried to implement this audio/non-audio switch by playing with ALSA controls, however there are a couple of problems: - the non-audio mode can only be set when the device is closed. There are some protections in alsa-lib, meaning we would need to set this mode on resume and go back to audio mode on suspend. - it took me a while to realize that everything I programmed using alsa controls (snd_ctl*) or configured with iecset on a command line was just overwritten with default values when playback starts. the alsa-lib hdmi/iec958 plugin resets all the values that you carefully programmed with snd_ctl* calls, you really have to pass an argument to this device when it is opened. Boils down to adding ,AES0=0x06 to the device name in passthrough mode. Is the ALSA device correctly being configured to 192 kHz? I will have to recheck for these two cases. I guess it is since I can see the D+ logo, but let me confirm for these two cases. The frequency is correctly set: more /proc/asound/card0/pcm3p/sub0/hw_params access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 192000 (192000/1) period_size: 8192 buffer_size: 16384 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
On 04/19/2011 02:03 PM, pl bossart wrote: I finally managed to figure out why eac3 wouldn't work in passthrough mode. Apparently my HDMI receiver will only lock on eac3 data if the AES0 control is set to 0x06 (non-audio, ie iec61937). ffmpeg -acodec copy -i csi_miami_5.1_256_spx.eac3 -f spdif outfile.pcm aplay -Dhdmi:AES0=0x6 -fs16 -c2 -r192000 outfile.pcm the same file plays well through pulseaudio if I modifed default.conf to [Mapping hdmi-stereo] device-strings = hdmi:%f,AES0=0x06 channel-map = left,right priority = 4 direction = output Somehow we need to find a way to set this AES0 byte when opening the iec958 or hdmi device in the passthrough code, and reset it back to 0x04 for PCM playback (should be fairly easy to do by looking at the code of iecset in alsa-utils). Beats me why this was not needed for plain ac3, but setting the audio bit is actually the correct thing to do. So far I haven't been able to get anything except stereo working with passthrough. It seems to me that selecting multiple channels in passthrough mode would be very similar to the necessary AES0 changes, so maybe we can get that fixed too. I've basically hit a wall by only being able to passthrough 192khz stereo. When the passthrough data rate exceeds the available rate, my code clips the data packets. Which seems to work OK when the excess is maybe 200 bytes or so. On some HD DTS I'm clipping more like 2K per packet which results in some very nasty sounds emanating from the speakers. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
So far I haven't been able to get anything except stereo working with passthrough. It seems to me that selecting multiple channels in passthrough mode would be very similar to the necessary AES0 changes, so maybe we can get that fixed too. I've basically hit a wall by only being able to passthrough 192khz stereo. When the passthrough data rate exceeds the available rate, my code clips the data packets. Which seems to work OK when the excess is maybe 200 bytes or so. On some HD DTS I'm clipping more like 2K per packet which results in some very nasty sounds emanating from the speakers. Looks like a know issue? I remember some comments/patches from Anssi that if you want to passthrough data at a rate of more than 6.144Mbit/s then yes you need to use AES0=0x06 so that the HMDI hardware uses HBR packets. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
On Tue, 2011-04-19 at 15:03 -0500, pl bossart wrote: I finally managed to figure out why eac3 wouldn't work in passthrough mode. Apparently my HDMI receiver will only lock on eac3 data if the AES0 control is set to 0x06 (non-audio, ie iec61937). ffmpeg -acodec copy -i csi_miami_5.1_256_spx.eac3 -f spdif outfile.pcm aplay -Dhdmi:AES0=0x6 -fs16 -c2 -r192000 outfile.pcm the same file plays well through pulseaudio if I modifed default.conf to [Mapping hdmi-stereo] device-strings = hdmi:%f,AES0=0x06 channel-map = left,right priority = 4 direction = output Somehow we need to find a way to set this AES0 byte when opening the iec958 or hdmi device in the passthrough code, and reset it back to 0x04 for PCM playback (should be fairly easy to do by looking at the code of iecset in alsa-utils). Beats me why this was not needed for plain ac3, but setting the audio bit is actually the correct thing to do. If my reading is correct, this is something we should do for all formats anyway? So far all the tests seem ok with the ffmpeg examples, with the exception of two files: - 7_pt_1: works well with ffmpeg, aplay but the sound is way too fast with pulseaudio. Lots of rewind messages seen in PulseAudio. - serenity_english_5.1_1536.eac3 file: no sound out, and again lots of rewind messages (the receiver still shows the D+ logo though). The same file converted with ffmpeg and played with aplay seems fine. looks like a buffering issue more than a payloader problem really. Is the ALSA device correctly being configured to 192 kHz? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
I finally managed to figure out why eac3 wouldn't work in passthrough mode. Apparently my HDMI receiver will only lock on eac3 data if the AES0 control is set to 0x06 (non-audio, ie iec61937). ffmpeg -acodec copy -i csi_miami_5.1_256_spx.eac3 -f spdif outfile.pcm aplay -Dhdmi:AES0=0x6 -fs16 -c2 -r192000 outfile.pcm the same file plays well through pulseaudio if I modifed default.conf to [Mapping hdmi-stereo] device-strings = hdmi:%f,AES0=0x06 channel-map = left,right priority = 4 direction = output Somehow we need to find a way to set this AES0 byte when opening the iec958 or hdmi device in the passthrough code, and reset it back to 0x04 for PCM playback (should be fairly easy to do by looking at the code of iecset in alsa-utils). Beats me why this was not needed for plain ac3, but setting the audio bit is actually the correct thing to do. So far all the tests seem ok with the ffmpeg examples, with the exception of two files: - 7_pt_1: works well with ffmpeg, aplay but the sound is way too fast with pulseaudio. Lots of rewind messages seen in PulseAudio. - serenity_english_5.1_1536.eac3 file: no sound out, and again lots of rewind messages (the receiver still shows the D+ logo though). The same file converted with ffmpeg and played with aplay seems fine. looks like a buffering issue more than a payloader problem really. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
On Thu, Apr 14, 2011 at 5:49 AM, Arun Raghavan arun.ragha...@collabora.co.uk wrote: On Wed, 2011-04-13 at 18:23 +0530, Arun Raghavan wrote: [...] The changes needed to actually use this in GStreamer are also done, but not upstream yet. I need to do some rebasing to make this stuff good to push out, so details on this in a following mail. Okay, this is also pushed and good to test. I'll be pushing this out to master after the next round of gst* releases (which should happen in the next couple of weeks or so). For now, you'll need: * gstreamer from git master * gst-plugins-base from: http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough * gst-plugins-good from: http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough * gst-plugins-bad, gst-plugins-ugly, gst-ffmpeg built against the above would probably also be needed (for non-passthrough playback) With all but the top-most commit to gst-plugins-good, pulsesink will be plugged in passthrough mode when the sink supports the format of the input. The top-most commit on gst-plugins-good introduces a new pulsesinkbin element, which automatically reconfigures based on what formats are available on the sink we're connected to. So if you're playing AC3 in passthrough mode over S/PDIF and switch to analog out, it'll transparently plug in a decoder, and if you switch back to digital out, the decoder will be removed and passthrough mode will be enabled again. pulsesinkbin will be autoplugged if your app (or gst-launch) is using playbin2, but most applications totem/rhythmbox/... override the playbin2 audio sink, so there's some work pending before this just works with players. I'm happy to help if anyone runs into problems while testing. Cheers, Arun p.s.: for those of you who want to test but don't have a gstreamer-from-git setup already, jhbuild[1] or gst-uninstalled[2] should be useful. I have been using this branch for awhile (since the first day XBMC could use it to passthrough DTS-HD) and will it worked for most that time yesterday I updated to the most recent git pull and now pulseaudio doesn't even see my Nvidia HDMI at all anymore. It doesn't show as a possible sink. This is on a XBMC-Live dedicated HTPC that nothing else has changed in recent time. I can still use HDMI by using straight Alsa so nothing happened to it. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
On Sat, Apr 16, 2011 at 9:39 AM, Dark Shadow shadowofdarkn...@gmail.com wrote: On Thu, Apr 14, 2011 at 5:49 AM, Arun Raghavan arun.ragha...@collabora.co.uk wrote: On Wed, 2011-04-13 at 18:23 +0530, Arun Raghavan wrote: [...] The changes needed to actually use this in GStreamer are also done, but not upstream yet. I need to do some rebasing to make this stuff good to push out, so details on this in a following mail. Okay, this is also pushed and good to test. I'll be pushing this out to master after the next round of gst* releases (which should happen in the next couple of weeks or so). For now, you'll need: * gstreamer from git master * gst-plugins-base from: http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough * gst-plugins-good from: http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough * gst-plugins-bad, gst-plugins-ugly, gst-ffmpeg built against the above would probably also be needed (for non-passthrough playback) With all but the top-most commit to gst-plugins-good, pulsesink will be plugged in passthrough mode when the sink supports the format of the input. The top-most commit on gst-plugins-good introduces a new pulsesinkbin element, which automatically reconfigures based on what formats are available on the sink we're connected to. So if you're playing AC3 in passthrough mode over S/PDIF and switch to analog out, it'll transparently plug in a decoder, and if you switch back to digital out, the decoder will be removed and passthrough mode will be enabled again. pulsesinkbin will be autoplugged if your app (or gst-launch) is using playbin2, but most applications totem/rhythmbox/... override the playbin2 audio sink, so there's some work pending before this just works with players. I'm happy to help if anyone runs into problems while testing. Cheers, Arun p.s.: for those of you who want to test but don't have a gstreamer-from-git setup already, jhbuild[1] or gst-uninstalled[2] should be useful. I have been using this branch for awhile (since the first day XBMC could use it to passthrough DTS-HD) and will it worked for most that time yesterday I updated to the most recent git pull and now pulseaudio doesn't even see my Nvidia HDMI at all anymore. It doesn't show as a possible sink. This is on a XBMC-Live dedicated HTPC that nothing else has changed in recent time. I can still use HDMI by using straight Alsa so nothing happened to it. Don't worry, it must of been a random problem after rolling back to old versions of your passthrough branch then moving up one commit at at time to try and track the breakage I made it back to the newest with it working again. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
On Wed, 2011-04-13 at 18:23 +0530, Arun Raghavan wrote: [...] The changes needed to actually use this in GStreamer are also done, but not upstream yet. I need to do some rebasing to make this stuff good to push out, so details on this in a following mail. Okay, this is also pushed and good to test. I'll be pushing this out to master after the next round of gst* releases (which should happen in the next couple of weeks or so). For now, you'll need: * gstreamer from git master * gst-plugins-base from: http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough * gst-plugins-good from: http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough * gst-plugins-bad, gst-plugins-ugly, gst-ffmpeg built against the above would probably also be needed (for non-passthrough playback) With all but the top-most commit to gst-plugins-good, pulsesink will be plugged in passthrough mode when the sink supports the format of the input. The top-most commit on gst-plugins-good introduces a new pulsesinkbin element, which automatically reconfigures based on what formats are available on the sink we're connected to. So if you're playing AC3 in passthrough mode over S/PDIF and switch to analog out, it'll transparently plug in a decoder, and if you switch back to digital out, the decoder will be removed and passthrough mode will be enabled again. pulsesinkbin will be autoplugged if your app (or gst-launch) is using playbin2, but most applications totem/rhythmbox/... override the playbin2 audio sink, so there's some work pending before this just works with players. I'm happy to help if anyone runs into problems while testing. Cheers, Arun p.s.: for those of you who want to test but don't have a gstreamer-from-git setup already, jhbuild[1] or gst-uninstalled[2] should be useful. [1]: http://live.gnome.org/Jhbuild [2]: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-developing.html#developing-uninstalled-gstreamer ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
