Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
# Encode AC3 - Directly on hardware # with Rate Converter to 48kHz, needed for some applications pcm.a52 { @args [ CARD ] @args.CARD { type integer } type rate slave { pcm { type a52 bitrate 448 channels 6 card $CARD } rate 48000 } } If I replace $CARD with 0 (manually), the above works - does anyone know why it doesn't work when I leave the $CARD there - shouldn't it get it from Pulseaudio when udev tries a52:0 ? Or is this not the correct way to do it? Cheers, Mike From: pl bossart bossart.nos...@gmail.com To: General PulseAudio Discussion pulseaudio-discuss@mail.0pointer.de Sent: Mon, 12 July, 2010 23:14:06 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support This may be an obvious question, but what is the @args.0 { type integer } for? Is that what you meant by Adding the argument removes the need to exit the profile. and if you did, I didn't understand at what point I had to exit the profile. Can you explain? Sorry if I'm being stupid. Oops, this is a typo. 'edit' the profile I meant, not exit You can keep a52:0 in the profile definition, no need to change pulseaudio configuration files. ___ 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] {PATCH][RFC] AC3 passthrough support
'Twas brillig, and Michael Rans at 13/07/10 19:53 did gyre and gimble: # Encode AC3 - Directly on hardware # with Rate Converter to 48kHz, needed for some applications pcm.a52 { @args [ CARD ] @args.CARD { type integer } type rate slave { pcm { type a52 bitrate 448 channels 6 card $CARD } rate 48000 } } If I replace $CARD with 0 (manually), the above works - does anyone know why it doesn't work when I leave the $CARD there - shouldn't it get it from Pulseaudio when udev tries a52:0 ? Or is this not the correct way to do it? Maybe I'm wrong with that syntax Does this work? pcm.a52 { @args.0 { type integer } type rate slave { pcm { type a52 bitrate 448 channels 6 card $0 } rate 48000 } } -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] 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][RFC] AC3 passthrough support
Adding this in /etc/asound.rc (more exactly /etc/alsa/pulse-default.conf on my Fedora box) work fine: pcm.a52 { @args [CARD] @args.CARD { type string } type rate slave { pcm { type a52 bitrate 448 channels 6 card $CARD } rate 48000 #required somehow, otherwise nothing happens in PulseAudio } } a52:0 is detected by PulseAudio and the encoded output shows as 'Digital Surround 5.1 (IEC958/AC3) in pavucontrol. I just finished testing all the changes I posted yesterday. Works flawlessly, I can switch from 2ch PCM over SPDIF to 5.1 still over SPDIF but re-encoded with a52, and unlike the passthrough case I can mix the multichannel content with alerts or system tones. The only bug I found is that if I change the individual volume on one of the channels, there's a ringing noise introduced, and it does not go away unless I kill the stream. Will prepare a set of patches, Colin it'd be great if you can merge them in git master. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
Strange - $CARD really won't work on my setup - it fails to create an a52 device. Can anyone else get it working? On Lucid? I tried it in ~/.asoundrc, /etc/asound.conf and /usr/share/alsa/alsa.conf and no luck. Cheers, Mike From: pl bossart bossart.nos...@gmail.com To: General PulseAudio Discussion pulseaudio-discuss@mail.0pointer.de Sent: Tue, 13 July, 2010 21:21:50 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support Adding this in /etc/asound.rc (more exactly /etc/alsa/pulse-default.conf on my Fedora box) work fine: pcm.a52 { @args [CARD] @args.CARD { type string } type rate slave { pcm { type a52 bitrate 448 channels 6 card $CARD } rate 48000 #required somehow, otherwise nothing happens in PulseAudio } } a52:0 is detected by PulseAudio and the encoded output shows as 'Digital Surround 5.1 (IEC958/AC3) in pavucontrol. I just finished testing all the changes I posted yesterday. Works flawlessly, I can switch from 2ch PCM over SPDIF to 5.1 still over SPDIF but re-encoded with a52, and unlike the passthrough case I can mix the multichannel content with alerts or system tones. The only bug I found is that if I change the individual volume on one of the channels, there's a ringing noise introduced, and it does not go away unless I kill the stream. Will prepare a set of patches, Colin it'd be great if you can merge them in git master. -Pierre ___ 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] {PATCH][RFC] AC3 passthrough support
On Sun, 2010-07-11 at 19:25 +, Michael Rans wrote: Frankly, I think it would be much better to have A52 in Pulseaudio with switchable channel maps so that there's one sink. Why is it so important to have only one sink? What's wrong with changing profiles? -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
Are we talking about the same sinks here? I mean there should be one Alsa sink (the physical digital output) ie. reduce Alsa to a driver providing only hardware sinks, not software sinks (like rate converters, A52 etc.). On the Pulseaudio side, two profiles using that one Alsa digital sink is fine. I don't have any preference about the Pulseaudio side - I just don't think a user should have to configure a .asoundrc with additional software sinks for Alsa. If the profile changing is such that the user cannot tell the difference between a change between 2 sound cards and a change between A52 and stereo on a single digital output, then that's fine. Cheers, Mike From: Tanu Kaskinen ta...@iki.fi To: pulseaudio-discuss@mail.0pointer.de Sent: Mon, 12 July, 2010 20:27:28 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support On Sun, 2010-07-11 at 19:25 +, Michael Rans wrote: Frankly, I think it would be much better to have A52 in Pulseaudio with switchable channel maps so that there's one sink. Why is it so important to have only one sink? What's wrong with changing profiles? -- Tanu Kaskinen ___ 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] {PATCH][RFC] AC3 passthrough support
Again, when reading the thread further, I found the reason why snd_pcm_hw_params_can_rewind doesn't exist - it was replaced by snd_pcm_rewindable. Pulseaudio doesn't call that. I added a patch (not formatted as a proper patch) to ticket 839 that adds the snd_pcm_rewindable check to the alsa sink. If you could test that and see if it helps with the rate converter plugin, I'll prepare a proper patch. Tanu, can you provide this fix? Couldn't find your patch, no bug #839. PulseAudio has another routine: pa_alsa_pcm_is_hw, this could also be used but it would prevent rewinds for iec958 as well... Thanks ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
On Mon, 2010-07-12 at 14:57 -0500, pl bossart wrote: Again, when reading the thread further, I found the reason why snd_pcm_hw_params_can_rewind doesn't exist - it was replaced by snd_pcm_rewindable. Pulseaudio doesn't call that. I added a patch (not formatted as a proper patch) to ticket 839 that adds the snd_pcm_rewindable check to the alsa sink. If you could test that and see if it helps with the rate converter plugin, I'll prepare a proper patch. Tanu, can you provide this fix? Couldn't find your patch, no bug #839. PulseAudio has another routine: pa_alsa_pcm_is_hw, this could also be used but it would prevent rewinds for iec958 as well... Oh, pa_alsa_pcm_is_hw seems useful. Currently it's only used for disabling tsched. I guess even with tsched disabled, pulseaudio still tries to do rewinding - I think it would make sense to set max rewind to zero if pa_alsa_pcm_is_hw returns false. You apparently didn't look hard enough for the ticket :) It was closed for a while, but I reopened it today. Here's the url: http://pulseaudio.org/ticket/839 -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
On Mon, 2010-07-12 at 14:57 -0500, pl bossart wrote: Tanu, can you provide this fix? Couldn't find your patch, no bug #839. PulseAudio has another routine: pa_alsa_pcm_is_hw, this could also be used but it would prevent rewinds for iec958 as well... Forgot this from the previous reply: Have you tested that pa_alsa_pcm_is_hw really returns FALSE for iec958? I thought iec958 is just an alias like front or surround51. The implementation uses snd_pcm_info_get_card(info) to determine the answer (valid card index - true, error - false). It seems probable that the function will return a valid card index for iec958. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
2. Replace: pa_sink_set_max_rewind(u-sink, u-hwbuf_size); with: if(strcmp(u-device_name, a52) == 0) { pa_sink_set_max_rewind(u-sink, 0); } else { pa_sink_set_max_rewind(u-sink, u-hwbuf_size); } NAK. This does not work for me. You need to rewind also in the thread context: diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c index 2995c3c..4059a9b 100644 --- a/src/modules/alsa/alsa-sink.c +++ b/src/modules/alsa/alsa-sink.c @@ -953,7 +953,12 @@ static int update_sw_params(struct userdata *u) { } pa_sink_set_max_request_within_thread(u-sink, u-hwbuf_size - u-hwbuf_unused); -pa_sink_set_max_rewind_within_thread(u-sink, u-hwbuf_size); + if (pa_alsa_pcm_is_hw(u-pcm_handle)) + pa_sink_set_max_rewind_within_thread(u-sink, u-hwbuf_size); +else { +pa_log(Disabling rewind_within_thread for device %s, u-device_name); +pa_sink_set_max_rewind_within_thread(u-sink, 0); +} return 0; } @@ -1906,7 +1911,12 @@ pa_sink *pa_alsa_sink_new(pa_module *m, pa_modargs *ma, const char*driver, pa_ca (double) pa_bytes_to_usec(u-hwbuf_size, ss) / PA_USEC_PER_MSEC); pa_sink_set_max_request(u-sink, u-hwbuf_size); -pa_sink_set_max_rewind(u-sink, u-hwbuf_size); +if (pa_alsa_pcm_is_hw(u-pcm_handle)) +pa_sink_set_max_rewind(u-sink, u-hwbuf_size); +else { +pa_log(Disabling rewind for device %s, u-device_name); +pa_sink_set_max_rewind(u-sink, 0); +} if (u-use_tsched) { u-tsched_watermark = pa_usec_to_bytes_round_up(pa_bytes_to_usec_round_up(tsched_watermark, requested_ss), u-sink-sample_spec); pa_pcm_is_hw detects a52 but allows rewind for iec958. Looks like a better fix than a hard-coded string compare. Even with this fix, the sink doesn't seem to do anything: D: alsa-sink.c: Requested to rewind 0 bytes. D: alsa-sink.c: Mhmm, actually there is nothing to rewind. D: protocol-native.c: Requesting rewind due to rewrite. D: sink-input.c: Requesting rewind due to corking D: alsa-sink.c: Requested to rewind 0 bytes. D: alsa-sink.c: Mhmm, actually there is nothing to rewind. D: module-suspend-on-idle.c: Sink alsa_output.pci-_00_1b.0.iec958-ac3-surround-51 becomes idle, timeout in 5 seconds. D: alsa-sink.c: Requested to rewind 0 bytes. D: module-suspend-on-idle.c: Sink alsa_output.pci-_00_1b.0.iec958-ac3-surround-51 becomes idle, timeout in 5 seconds. D: alsa-sink.c: Mhmm, actually there is nothing to rewind. D: protocol-dbus.c: Interface org.PulseAudio.Core1.Stream removed from object /org/pulseaudio/core1/playback_stream0 I: sink-input.c: Freeing input 0 Playback Stream I: client.c: Freed 5 gst-launch-0.10 I: protocol-native.c: Connection died. You'll find my diffs against git master below: - Pierre masterdiff.patch Description: Binary data ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
Cool - I'm glad you got rid of the a52 string check hack. I didn't have the line pa_sink_set_max_rewind_within_thread(u-sink, u-hwbuf_size); I guess the version of Pulseaudio source code in Lucid is much older than yours? Anyway I did have the line with pa_sink_set_max_request_within_thread so I added your lines below and didn't get any compile errors, so the function exists in my version, just wasn't used. It still all works for me. Cheers, Mike From: pl bossart bossart.nos...@gmail.com To: General PulseAudio Discussion pulseaudio-discuss@mail.0pointer.de Sent: Mon, 12 July, 2010 22:08:44 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support 2. Replace: pa_sink_set_max_rewind(u-sink, u-hwbuf_size); with: if(strcmp(u-device_name, a52) == 0) { pa_sink_set_max_rewind(u-sink, 0); } else { pa_sink_set_max_rewind(u-sink, u-hwbuf_size); } NAK. This does not work for me. You need to rewind also in the thread context: diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c index 2995c3c..4059a9b 100644 --- a/src/modules/alsa/alsa-sink.c +++ b/src/modules/alsa/alsa-sink.c @@ -953,7 +953,12 @@ static int update_sw_params(struct userdata *u) { } pa_sink_set_max_request_within_thread(u-sink, u-hwbuf_size - u-hwbuf_unused); -pa_sink_set_max_rewind_within_thread(u-sink, u-hwbuf_size); + if (pa_alsa_pcm_is_hw(u-pcm_handle)) + pa_sink_set_max_rewind_within_thread(u-sink, u-hwbuf_size); +else { +pa_log(Disabling rewind_within_thread for device %s, u-device_name); +pa_sink_set_max_rewind_within_thread(u-sink, 0); +} return 0; } @@ -1906,7 +1911,12 @@ pa_sink *pa_alsa_sink_new(pa_module *m, pa_modargs *ma, const char*driver, pa_ca (double) pa_bytes_to_usec(u-hwbuf_size, ss) / PA_USEC_PER_MSEC); pa_sink_set_max_request(u-sink, u-hwbuf_size); -pa_sink_set_max_rewind(u-sink, u-hwbuf_size); +if (pa_alsa_pcm_is_hw(u-pcm_handle)) +pa_sink_set_max_rewind(u-sink, u-hwbuf_size); +else { +pa_log(Disabling rewind for device %s, u-device_name); +pa_sink_set_max_rewind(u-sink, 0); +} if (u-use_tsched) { u-tsched_watermark = pa_usec_to_bytes_round_up(pa_bytes_to_usec_round_up(tsched_watermark, requested_ss), u-sink-sample_spec); pa_pcm_is_hw detects a52 but allows rewind for iec958. Looks like a better fix than a hard-coded string compare. Even with this fix, the sink doesn't seem to do anything: D: alsa-sink.c: Requested to rewind 0 bytes. D: alsa-sink.c: Mhmm, actually there is nothing to rewind. D: protocol-native.c: Requesting rewind due to rewrite. D: sink-input.c: Requesting rewind due to corking D: alsa-sink.c: Requested to rewind 0 bytes. D: alsa-sink.c: Mhmm, actually there is nothing to rewind. D: module-suspend-on-idle.c: Sink alsa_output.pci-_00_1b.0.iec958-ac3-surround-51 becomes idle, timeout in 5 seconds. D: alsa-sink.c: Requested to rewind 0 bytes. D: module-suspend-on-idle.c: Sink alsa_output.pci-_00_1b.0.iec958-ac3-surround-51 becomes idle, timeout in 5 seconds. D: alsa-sink.c: Mhmm, actually there is nothing to rewind. D: protocol-dbus.c: Interface org.PulseAudio.Core1.Stream removed from object /org/pulseaudio/core1/playback_stream0 I: sink-input.c: Freeing input 0 Playback Stream I: client.c: Freed 5 gst-launch-0.10 I: protocol-native.c: Connection died. You'll find my diffs against git master below: - Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
Even with this fix, the sink doesn't seem to do anything: Actually discard this comment, it looks like it's crunching data if you specify the rate in asound.conf. # Encode AC3 - Directly on hardware pcm.Filter_A52Encode { type a52 bitrate 448 channels 6 } # Rate Converter to 48kHz, needed for some applications pcm.a52 { @args.0 { type integer } type rate slave { pcm Filter_A52Encode rate 48000 } } Adding the argument removes the need to exit the profile. It's really odd that the rate plugin is required even though everything is already configured at 48kHz. I will test tomorrow and if this is fine then I'll prepare a patch for upstream. Thanks for doing the groundwork for this bug. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
You're welcome. This may be an obvious question, but what is the @args.0 { type integer } for? Is that what you meant by Adding the argument removes the need to exit the profile. and if you did, I didn't understand at what point I had to exit the profile. Can you explain? Sorry if I'm being stupid. Cheers, Mike From: pl bossart bossart.nos...@gmail.com To: General PulseAudio Discussion pulseaudio-discuss@mail.0pointer.de Sent: Mon, 12 July, 2010 22:29:18 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support Even with this fix, the sink doesn't seem to do anything: Actually discard this comment, it looks like it's crunching data if you specify the rate in asound.conf. # Encode AC3 - Directly on hardware pcm.Filter_A52Encode { type a52 bitrate 448 channels 6 } # Rate Converter to 48kHz, needed for some applications pcm.a52 { @args.0 { type integer } type rate slave { pcm Filter_A52Encode rate 48000 } } Adding the argument removes the need to exit the profile. It's really odd that the rate plugin is required even though everything is already configured at 48kHz. I will test tomorrow and if this is fine then I'll prepare a patch for upstream. Thanks for doing the groundwork for this bug. ___ 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] {PATCH][RFC] AC3 passthrough support
This may be an obvious question, but what is the @args.0 { type integer } for? Is that what you meant by Adding the argument removes the need to exit the profile. and if you did, I didn't understand at what point I had to exit the profile. Can you explain? Sorry if I'm being stupid. Oops, this is a typo. 'edit' the profile I meant, not exit You can keep a52:0 in the profile definition, no need to change pulseaudio configuration files. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
On Sat, 2010-07-10 at 13:24 +, Michael Rans wrote: I can't find any definition of snd_pcm_rewind() in the alsa-plugins source code. Does this function call through to a function in the plugins? snd_pcm_rewind() is in alsa-lib, not alsa-plugins. I don't know how the plugins do rewinding - I didn't find any rewind callbacks in the rate converter nor in the pulse plugin code. (I'm not familiar with alsa code, so I might have looked at the wrong places.) I understand that there a function snd_pcm_hw_params_can_rewind which I would guess should return false for AC3 encoding - is this called by Pulseaudio? Where did you find that function? The only mention that I found was in an alsa-devel discussion in 2008. I didn't find it in the alsa api documentation. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
On Sun, 2010-07-11 at 09:10 +0300, Tanu Kaskinen wrote: On Sat, 2010-07-10 at 13:24 +, Michael Rans wrote: I can't find any definition of snd_pcm_rewind() in the alsa-plugins source code. Does this function call through to a function in the plugins? snd_pcm_rewind() is in alsa-lib, not alsa-plugins. I don't know how the plugins do rewinding - I didn't find any rewind callbacks in the rate converter nor in the pulse plugin code. (I'm not familiar with alsa code, so I might have looked at the wrong places.) Update: when reading the rest of the thread that mentioned snd_pcm_hw_params_can_rewind, I saw this from Jaroslav Kysela: The rewind/forward implementation in ioplug is actually broken, because it moves only internal pointer without notification to real external plugin. So apparently the alsa plugins are completely unable to do proper rewinding, unless things have got better during the last two years. I understand that there a function snd_pcm_hw_params_can_rewind which I would guess should return false for AC3 encoding - is this called by Pulseaudio? Where did you find that function? The only mention that I found was in an alsa-devel discussion in 2008. I didn't find it in the alsa api documentation. Again, when reading the thread further, I found the reason why snd_pcm_hw_params_can_rewind doesn't exist - it was replaced by snd_pcm_rewindable. Pulseaudio doesn't call that. I added a patch (not formatted as a proper patch) to ticket 839 that adds the snd_pcm_rewindable check to the alsa sink. If you could test that and see if it helps with the rate converter plugin, I'll prepare a proper patch. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
At the moment I can switch between A52 and stereo SPDIF but it requires file editing and restarting Pulseaudio. 1. I haven't tried the new profiles yet - does this mean with the profiles in a GUI, I would be able to switch from A52 to stereo SPDIF output without editing any files or restarting Pulseaudio? 2. Would I be able to switch while music is playing between stereo and A52 and back (as is currently possible between my SPDIF and HDMI on different soundcards)? Cheers, Mike From: Tanu Kaskinen ta...@iki.fi To: pulseaudio-discuss@mail.0pointer.de Sent: Sun, 11 July, 2010 6:47:14 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support On Sat, 2010-07-10 at 15:40 +, Michael Rans wrote: Regarding AC3 encoding in Pulseaudio - it would be better because at the moment switching between stereo and A52 is not possible (ie. I cannot have both these lines in default.pa: load-module module-alsa-sink device=Filter_RateConvert rate=48000 sink_properties=device.description=AC3 sink_name=AC3 load-module module-alsa-sink device=ALC889A_Digital sink_properties=device.description=SPDIF sink_name=SPDIF Presumably the SPDIF out is locked by one of them, then the other fails. With ac3 encoding in Pulseaudio, this would be switchable without editing any files. Switching between stereo and a52 does not require doing the encoding in pulseaudio. Pulseaudio already provides both stereo and a52 spdif profiles for alsa cards with spdif output. The a52 profile uses the alsa plugin to do the encoding. The only problem is, as you know, that the a52 alsa plugin doesn't seem to work with pulseaudio (at least without the rate converter workaround). Fixing the plugin (or pulseaudio, if the cause actually is in pulseaudio) instead of implementing ac3 encoding in pulseaudio would be a perfectly fine solution. -- Tanu Kaskinen ___ 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] {PATCH][RFC] AC3 passthrough support
On Sun, 2010-07-11 at 08:43 +, Michael Rans wrote: At the moment I can switch between A52 and stereo SPDIF but it requires file editing and restarting Pulseaudio. 1. I haven't tried the new profiles yet - does this mean with the profiles in a GUI, I would be able to switch from A52 to stereo SPDIF output without editing any files or restarting Pulseaudio? Yes. And the A52 profile is not new, it's at least a year old now. The profile that I mean should show up as Digital Surround 5.1 (IEC958/AC3) Output in the card profile list, while the stereo profile is Digital Stereo (IEC958) Output or Digital Stereo Duplex (IEC958) (the latter actually means that only output is enabled, no input at all - that's a bug). 2. Would I be able to switch while music is playing between stereo and A52 and back (as is currently possible between my SPDIF and HDMI on different soundcards)? The switching requires changing the card profile, because both sinks (spdif/stereo and spdif/a52) can't exist at the same time. So, just select the card profile and you're done. Except I think it's possible that your music gets routed to some wrong sink, so you may need to also move the music stream after switching the card profile. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
That's the the problem - as you put it both sinks (spdif/stereo and spdif/a52) can't exist at the same time. If A52 encoding occurred in Pulseaudio, there would only be one sink, hence the switch between stereo and A52 would be transparent and could occur even while the music is playing (with a small interruption). Is the A52 profile in Ubuntu Lucid 10.04LTS? Cheers, Mike From: Tanu Kaskinen ta...@iki.fi To: pulseaudio-discuss@mail.0pointer.de Sent: Sun, 11 July, 2010 10:15:12 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support On Sun, 2010-07-11 at 08:43 +, Michael Rans wrote: At the moment I can switch between A52 and stereo SPDIF but it requires file editing and restarting Pulseaudio. 1. I haven't tried the new profiles yet - does this mean with the profiles in a GUI, I would be able to switch from A52 to stereo SPDIF output without editing any files or restarting Pulseaudio? Yes. And the A52 profile is not new, it's at least a year old now. The profile that I mean should show up as Digital Surround 5.1 (IEC958/AC3) Output in the card profile list, while the stereo profile is Digital Stereo (IEC958) Output or Digital Stereo Duplex (IEC958) (the latter actually means that only output is enabled, no input at all - that's a bug). 2. Would I be able to switch while music is playing between stereo and A52 and back (as is currently possible between my SPDIF and HDMI on different soundcards)? The switching requires changing the card profile, because both sinks (spdif/stereo and spdif/a52) can't exist at the same time. So, just select the card profile and you're done. Except I think it's possible that your music gets routed to some wrong sink, so you may need to also move the music stream after switching the card profile. -- Tanu Kaskinen ___ 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] {PATCH][RFC] AC3 passthrough support
Regarding your patch, I tried it but I got a seg fault. I also tried: size_t max_rewind = PA_MIN(u-hwbuf_size, snd_pcm_rewindable(u-pcm_handle)); pa_sink_set_max_rewind(u-sink, max_rewind); But u-pcm_handle is not populated at that stage as far as I can tell. From: Tanu Kaskinen ta...@iki.fi To: pulseaudio-discuss@mail.0pointer.de Sent: Sun, 11 July, 2010 7:48:15 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support On Sun, 2010-07-11 at 09:10 +0300, Tanu Kaskinen wrote: On Sat, 2010-07-10 at 13:24 +, Michael Rans wrote: I can't find any definition of snd_pcm_rewind() in the alsa-plugins source code. Does this function call through to a function in the plugins? snd_pcm_rewind() is in alsa-lib, not alsa-plugins. I don't know how the plugins do rewinding - I didn't find any rewind callbacks in the rate converter nor in the pulse plugin code. (I'm not familiar with alsa code, so I might have looked at the wrong places.) Update: when reading the rest of the thread that mentioned snd_pcm_hw_params_can_rewind, I saw this from Jaroslav Kysela: The rewind/forward implementation in ioplug is actually broken, because it moves only internal pointer without notification to real external plugin. So apparently the alsa plugins are completely unable to do proper rewinding, unless things have got better during the last two years. I understand that there a function snd_pcm_hw_params_can_rewind which I would guess should return false for AC3 encoding - is this called by Pulseaudio? Where did you find that function? The only mention that I found was in an alsa-devel discussion in 2008. I didn't find it in the alsa api documentation. Again, when reading the thread further, I found the reason why snd_pcm_hw_params_can_rewind doesn't exist - it was replaced by snd_pcm_rewindable. Pulseaudio doesn't call that. I added a patch (not formatted as a proper patch) to ticket 839 that adds the snd_pcm_rewindable check to the alsa sink. If you could test that and see if it helps with the rate converter plugin, I'll prepare a proper patch. -- Tanu Kaskinen ___ 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] {PATCH][RFC] AC3 passthrough support
On Sun, 2010-07-11 at 09:26 +, Michael Rans wrote: That's the the problem - as you put it both sinks (spdif/stereo and spdif/a52) can't exist at the same time. If A52 encoding occurred in Pulseaudio, there would only be one sink, hence the switch between stereo and A52 would be transparent and could occur even while the music is playing (with a small interruption). No, doing the encoding in pulseaudio wouldn't change the situation. There must be separate sinks for stereo and surround modes, because sinks can't change their channel map on the fly. (Of course that could be changed, but I don't think such change gets lots of support from the developers.) What do you mean by transparent? You can change the profile while music plays, that's not a problem. Is the A52 profile in Ubuntu Lucid 10.04LTS? Most likely yes. I now actually checked what's the situation with the a52 profile on my own machine. I don't have the profile available, even though I have other spdif profiles, so I looked at the initialization to see what's wrong, and found this: D: alsa-mixer.c: Looking at profile output:iec958-ac3-surround-40 D: alsa-mixer.c: Checking for playback on Digital Surround 4.0 (IEC958/AC3) (iec958-ac3-surround-40) D: alsa-util.c: Trying a52:0 with SND_PCM_NO_AUTO_FORMAT ... I: (alsa-lib)pcm.c: Unknown PCM a52:0 I: alsa-util.c: Error opening PCM device a52:0: No such file or directory So alsa doesn't find the a52 device at all, even though I do seem to have the plugin installed (this file exists: /usr/lib/alsa-lib/libasound/libasound_module_pcm_a52.so). I don't feel like experimenting, but I would guess that device string a52 instead of a52:0 would work better. ...nah, I did feel like experimenting after all, since all I had to do was to edit one file (/usr/local/share/pulseaudio/alsa-mixer/profile-sets/default.conf) and do some pulseaudio restarting. It turned out that plain a52 didn't work any better, so what's wrong? Well, at least on Debian there is no device configured by default that would use the a52 plugin, so I had to add this to ~/.asoundrc: pcm.a52 { type a52 } Now I got further: D: alsa-mixer.c: Looking at profile output:iec958-ac3-surround-40 D: alsa-mixer.c: Checking for playback on Digital Surround 4.0 (IEC958/AC3) (iec958-ac3-surround-40) D: alsa-util.c: Trying a52:0 with SND_PCM_NO_AUTO_FORMAT ... I: (alsa-lib)conf.c: Unknown parameters 0 I: (alsa-lib)pcm.c: Unknown PCM a52:0 I: alsa-util.c: Error opening PCM device a52:0: Invalid argument D: alsa-util.c: Trying a52 with SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open a52 D: alsa-util.c: snd_pcm_hw_params_set_channels(4) failed: Invalid argument D: alsa-util.c: Trying a52 without SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open a52 D: alsa-util.c: snd_pcm_hw_params_set_channels(4) failed: Invalid argument D: alsa-util.c: Trying plug:a52 with SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open plug:a52 D: alsa-util.c: snd_pcm_hw_params_set_channels(4) failed: Invalid argument D: alsa-util.c: Trying plug:a52 without SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open plug:a52 D: alsa-util.c: snd_pcm_hw_params_set_channels(4) failed: Invalid argument I: alsa-util.c: Failed to set hardware parameters on plug:a52: Invalid argument That looks good (that's the 4.0 profile, and by default the a52 plugin uses the 5.1 channel configuration, so the failure is expected). From that log we can see that indeed, a52:0 doesn't work, but a52 does. That means that you don't have the profile available, because you don't have the modification in your profile set configuration. So, what about the 5.1 profile? D: alsa-mixer.c: Looking at profile output:iec958-ac3-surround-51 D: alsa-mixer.c: Checking for playback on Digital Surround 5.1 (IEC958/AC3) (iec958-ac3-surround-51) D: alsa-util.c: Trying a52:0 with SND_PCM_NO_AUTO_FORMAT ... I: (alsa-lib)conf.c: Unknown parameters 0 I: (alsa-lib)pcm.c: Unknown PCM a52:0 I: alsa-util.c: Error opening PCM device a52:0: Invalid argument D: alsa-util.c: Trying a52 with SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open a52 D: alsa-util.c: Maximum hw buffer size is 320 ms D: alsa-util.c: Set buffer size first (to 4797 samples), period size second (to 1199 samples). I: alsa-util.c: Device a52 doesn't support 44100 Hz, changed to 48000 Hz. D: alsa-mixer.c: Profile output:iec958-ac3-surround-51 supported. Whee, it works! I don't have anything to connect the digital output, though, so I didn't test actual playback, but at least the profile is now available. So, the first problem when trying to make the a52 alsa plugin work out of the box with pulseaudio is that (at least on all distros) the a52 device isn't configured by default. I think it's the job for the distributions to automatically configure the device when the a52 plugin is installed. The second problem is that the a52 device doesn't support the card argument. I would imagine that the a52 plugin can
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
Thanks for this detailed reply. Would I be right in saying that for this to happen, you cannot define your own sinks in default.pa using load-module module-alsa-sink ... but must use the moduel detection? Or can profiles be made to work with the load-module module-alsa-sink ... lines? Cheers, Mike From: Tanu Kaskinen ta...@iki.fi To: pulseaudio-discuss@mail.0pointer.de Sent: Sun, 11 July, 2010 12:23:25 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support On Sun, 2010-07-11 at 09:26 +, Michael Rans wrote: That's the the problem - as you put it both sinks (spdif/stereo and spdif/a52) can't exist at the same time. If A52 encoding occurred in Pulseaudio, there would only be one sink, hence the switch between stereo and A52 would be transparent and could occur even while the music is playing (with a small interruption). No, doing the encoding in pulseaudio wouldn't change the situation. There must be separate sinks for stereo and surround modes, because sinks can't change their channel map on the fly. (Of course that could be changed, but I don't think such change gets lots of support from the developers.) What do you mean by transparent? You can change the profile while music plays, that's not a problem. Is the A52 profile in Ubuntu Lucid 10.04LTS? Most likely yes. I now actually checked what's the situation with the a52 profile on my own machine. I don't have the profile available, even though I have other spdif profiles, so I looked at the initialization to see what's wrong, and found this: D: alsa-mixer.c: Looking at profile output:iec958-ac3-surround-40 D: alsa-mixer.c: Checking for playback on Digital Surround 4.0 (IEC958/AC3) (iec958-ac3-surround-40) D: alsa-util.c: Trying a52:0 with SND_PCM_NO_AUTO_FORMAT ... I: (alsa-lib)pcm.c: Unknown PCM a52:0 I: alsa-util.c: Error opening PCM device a52:0: No such file or directory So alsa doesn't find the a52 device at all, even though I do seem to have the plugin installed (this file exists: /usr/lib/alsa-lib/libasound/libasound_module_pcm_a52.so). I don't feel like experimenting, but I would guess that device string a52 instead of a52:0 would work better. ...nah, I did feel like experimenting after all, since all I had to do was to edit one file (/usr/local/share/pulseaudio/alsa-mixer/profile-sets/default.conf) and do some pulseaudio restarting. It turned out that plain a52 didn't work any better, so what's wrong? Well, at least on Debian there is no device configured by default that would use the a52 plugin, so I had to add this to ~/.asoundrc: pcm.a52 { type a52 } Now I got further: D: alsa-mixer.c: Looking at profile output:iec958-ac3-surround-40 D: alsa-mixer.c: Checking for playback on Digital Surround 4.0 (IEC958/AC3) (iec958-ac3-surround-40) D: alsa-util.c: Trying a52:0 with SND_PCM_NO_AUTO_FORMAT ... I: (alsa-lib)conf.c: Unknown parameters 0 I: (alsa-lib)pcm.c: Unknown PCM a52:0 I: alsa-util.c: Error opening PCM device a52:0: Invalid argument D: alsa-util.c: Trying a52 with SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open a52 D: alsa-util.c: snd_pcm_hw_params_set_channels(4) failed: Invalid argument D: alsa-util.c: Trying a52 without SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open a52 D: alsa-util.c: snd_pcm_hw_params_set_channels(4) failed: Invalid argument D: alsa-util.c: Trying plug:a52 with SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open plug:a52 D: alsa-util.c: snd_pcm_hw_params_set_channels(4) failed: Invalid argument D: alsa-util.c: Trying plug:a52 without SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open plug:a52 D: alsa-util.c: snd_pcm_hw_params_set_channels(4) failed: Invalid argument I: alsa-util.c: Failed to set hardware parameters on plug:a52: Invalid argument That looks good (that's the 4.0 profile, and by default the a52 plugin uses the 5.1 channel configuration, so the failure is expected). From that log we can see that indeed, a52:0 doesn't work, but a52 does. That means that you don't have the profile available, because you don't have the modification in your profile set configuration. So, what about the 5.1 profile? D: alsa-mixer.c: Looking at profile output:iec958-ac3-surround-51 D: alsa-mixer.c: Checking for playback on Digital Surround 5.1 (IEC958/AC3) (iec958-ac3-surround-51) D: alsa-util.c: Trying a52:0 with SND_PCM_NO_AUTO_FORMAT ... I: (alsa-lib)conf.c: Unknown parameters 0 I: (alsa-lib)pcm.c: Unknown PCM a52:0 I: alsa-util.c: Error opening PCM device a52:0: Invalid argument D: alsa-util.c: Trying a52 with SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open a52 D: alsa-util.c: Maximum hw buffer size is 320 ms D: alsa-util.c: Set buffer size first (to 4797 samples), period size second (to 1199 samples). I: alsa-util.c: Device a52 doesn't support 44100 Hz, changed to 48000 Hz. D: alsa-mixer.c: Profile output:iec958-ac3-surround-51 supported. Whee, it works! I don't have anything to connect
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
Further to my email below, I find that using udev detection and the change you suggested to default.conf, I get resource busy - I don't think my card likes it that it's SPDIF is opened twice, once as a stereo digital device and again through A52: E: alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 11549256 bytes (21823 ms). E: alsa-util.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers. ... E: alsa-util.c: snd_pcm_mmap_begin() returned a value that is exceptionally large: 11549256 bytes (21823 ms). E: alsa-util.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers. ... D: alsa-sink.c: snd_pcm_mmap_commit: Resource temporarily unavailable E: alsa-sink.c: Assertion 'err != -11' failed at modules/alsa/alsa-sink.c:395, function try_recover(). Aborting. Assuming this is not just my system's problem, this would be why a Pulseaudio A52 plugin would be better. Cheers, Mike From: Michael Rans mcar...@yahoo.co.uk To: General PulseAudio Discussion pulseaudio-discuss@mail.0pointer.de Sent: Sun, 11 July, 2010 18:40:36 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support Thanks for this detailed reply. Would I be right in saying that for this to happen, you cannot define your own sinks in default.pa using load-module module-alsa-sink ... but must use the moduel detection? Or can profiles be made to work with the load-module module-alsa-sink ... lines? Cheers, Mike From: Tanu Kaskinen ta...@iki.fi To: pulseaudio-discuss@mail.0pointer.de Sent: Sun, 11 July, 2010 12:23:25 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support On Sun, 2010-07-11 at 09:26 +, Michael Rans wrote: That's the the problem - as you put it both sinks (spdif/stereo and spdif/a52) can't exist at the same time. If A52 encoding occurred in Pulseaudio, there would only be one sink, hence the switch between stereo and A52 would be transparent and could occur even while the music is playing (with a small interruption). No, doing the encoding in pulseaudio wouldn't change the situation. There must be separate sinks for stereo and surround modes, because sinks can't change their channel map on the fly. (Of course that could be changed, but I don't think such change gets lots of support from the developers.) What do you mean by transparent? You can change the profile while music plays, that's not a problem. Is the A52 profile in Ubuntu Lucid 10.04LTS? Most likely yes. I now actually checked what's the situation with the a52 profile on my own machine. I don't have the profile available, even though I have other spdif profiles, so I looked at the initialization to see what's wrong, and found this: D: alsa-mixer.c: Looking at profile output:iec958-ac3-surround-40 D: alsa-mixer.c: Checking for playback on Digital Surround 4.0 (IEC958/AC3) (iec958-ac3-surround-40) D: alsa-util.c: Trying a52:0 with SND_PCM_NO_AUTO_FORMAT ... I: (alsa-lib)pcm.c: Unknown PCM a52:0 I: alsa-util.c: Error opening PCM device a52:0: No such file or directory So alsa doesn't find the a52 device at all, even though I do seem to have the plugin installed (this file exists: /usr/lib/alsa-lib/libasound/libasound_module_pcm_a52.so). I don't feel like experimenting, but I would guess that device string a52 instead of a52:0 would work better. ...nah, I did feel like experimenting after all, since all I had to do was to edit one file (/usr/local/share/pulseaudio/alsa-mixer/profile-sets/default.conf) and do some pulseaudio restarting. It turned out that plain a52 didn't work any better, so what's wrong? Well, at least on Debian there is no device configured by default that would use the a52 plugin, so I had to add this to ~/.asoundrc: pcm.a52 { type a52 } Now I got further: D: alsa-mixer.c: Looking at profile output:iec958-ac3-surround-40 D: alsa-mixer.c: Checking for playback on Digital Surround 4.0 (IEC958/AC3) (iec958-ac3-surround-40) D: alsa-util.c: Trying a52:0 with SND_PCM_NO_AUTO_FORMAT ... I: (alsa-lib)conf.c: Unknown parameters 0 I: (alsa-lib)pcm.c: Unknown PCM a52:0 I: alsa-util.c: Error opening PCM device a52:0: Invalid argument D: alsa-util.c: Trying a52 with SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open a52 D: alsa-util.c: snd_pcm_hw_params_set_channels(4) failed: Invalid argument D: alsa-util.c: Trying a52 without SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open a52 D: alsa-util.c: snd_pcm_hw_params_set_channels(4) failed: Invalid argument D: alsa-util.c: Trying plug:a52 with SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open plug:a52 D: alsa-util.c: snd_pcm_hw_params_set_channels(4) failed: Invalid argument D: alsa-util.c: Trying plug:a52 without SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Managed to open plug:a52 D: alsa-util.c: snd_pcm_hw_params_set_channels(4
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
Ah ok ignore that - I finally found what Colin's patch fixes :-) It is specifically when using udev (not alsa module loading as I have been previously) that it has an effect ie. if you have: load-module module-alsa-sink device=a52 rate=48000 sink_properties=device.description=a52 sink_name=a52 load-module module-alsa-sink device=ALC889A_Digital sink_properties=device.description=SPDIF sink_name=SPDIF it won't help, but if you use udev and udev loads SPDIF stereo and A52, then it seems to work (although I am having other issues). Frankly, I think it would be much better to have A52 in Pulseaudio with switchable channel maps so that there's one sink. I'll see how much further I can get with this. Cheers, Mike From: Michael Rans mcar...@yahoo.co.uk To: General PulseAudio Discussion pulseaudio-discuss@mail.0pointer.de Sent: Sun, 11 July, 2010 19:40:23 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support Further to my email below, I find that using udev detection and the change you suggested to default.conf, I get resource busy - I don't think my card likes it that it's SPDIF is opened twice, once as a stereo digital device and again through A52: E: alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 11549256 bytes (21823 ms). E: alsa-util.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers. ... E: alsa-util.c: snd_pcm_mmap_begin() returned a value that is exceptionally large: 11549256 bytes (21823 ms). E: alsa-util.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers. ... D: alsa-sink.c: snd_pcm_mmap_commit: Resource temporarily unavailable E: alsa-sink.c: Assertion 'err != -11' failed at modules/alsa/alsa-sink.c:395, function try_recover(). Aborting. Assuming this is not just my system's problem, this would be why a Pulseaudio A52 plugin would be better. Cheers, Mike From: Michael Rans mcar...@yahoo.co.uk To: General PulseAudio Discussion pulseaudio-discuss@mail.0pointer.de Sent: Sun, 11 July, 2010 18:40:36 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support Thanks for this detailed reply. Would I be right in saying that for this to happen, you cannot define your own sinks in default.pa using load-module module-alsa-sink ... but must use the moduel detection? Or can profiles be made to work with the load-module module-alsa-sink ... lines? Cheers, Mike From: Tanu Kaskinen ta...@iki.fi To: pulseaudio-discuss@mail.0pointer.de Sent: Sun, 11 July, 2010 12:23:25 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support On Sun, 2010-07-11 at 09:26 +, Michael Rans wrote: That's the the problem - as you put it both sinks (spdif/stereo and spdif/a52) can't exist at the same time. If A52 encoding occurred in Pulseaudio, there would only be one sink, hence the switch between stereo and A52 would be transparent and could occur even while the music is playing (with a small interruption). No, doing the encoding in pulseaudio wouldn't change the situation. There must be separate sinks for stereo and surround modes, because sinks can't change their channel map on the fly. (Of course that could be changed, but I don't think such change gets lots of support from the developers.) What do you mean by transparent? You can change the profile while music plays, that's not a problem. Is the A52 profile in Ubuntu Lucid 10.04LTS? Most likely yes. I now actually checked what's the situation with the a52 profile on my own machine. I don't have the profile available, even though I have other spdif profiles, so I looked at the initialization to see what's wrong, and found this: D: alsa-mixer.c: Looking at profile output:iec958-ac3-surround-40 D: alsa-mixer.c: Checking for playback on Digital Surround 4.0 (IEC958/AC3) (iec958-ac3-surround-40) D: alsa-util.c: Trying a52:0 with SND_PCM_NO_AUTO_FORMAT ... I: (alsa-lib)pcm.c: Unknown PCM a52:0 I: alsa-util.c: Error opening PCM device a52:0: No such file or directory So alsa doesn't find the a52 device at all, even though I do seem to have the plugin installed (this file exists: /usr/lib/alsa-lib/libasound/libasound_module_pcm_a52.so). I don't feel like experimenting, but I would guess that device string a52 instead of a52:0 would work better. ...nah, I did feel like experimenting after all, since all I had to do was to edit one file (/usr/local/share/pulseaudio/alsa-mixer/profile-sets/default.conf) and do some pulseaudio restarting. It turned out that plain a52 didn't work any better, so what's wrong? Well, at least on Debian there is no device configured by default that would use the a52 plugin, so I had to add this to ~/.asoundrc: pcm.a52 { type a52 } Now I got further: D: alsa-mixer.c: Looking at profile output:iec958-ac3-surround-40 D
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
Finally I got it all working! These are the steps on Ubuntu Lucid 10.04 LTS: 1. Open from Pulse source code: src/modules/alsa/alsa-sink.c 2. Replace: pa_sink_set_max_rewind(u-sink, u-hwbuf_size); with: if(strcmp(u-device_name, a52) == 0) { pa_sink_set_max_rewind(u-sink, 0); } else { pa_sink_set_max_rewind(u-sink, u-hwbuf_size); } 3. Add Colin's patch: if (PA_UNLIKELY((sframes = snd_pcm_mmap_commit(u-pcm_handle, offset, frames)) 0)) { +if (!after_avail (int) sframes == -EAGAIN) +break; + if ((r = try_recover(u, snd_pcm_mmap_commit, (int) sframes)) == 0) continue; 4. Compile and install Pulseaudio with udev support: make and sudo make install 5. Edit /usr/local/share/pulseaudio/alsa-mixer/profile-sets/default.conf: change a52:%f to a52 6. Copy /etc/pulse/daemon.conf to ~/.pulse/daemon.conf and ensure it has uncommented: default-sample-rate = 48000 7. Edit ~/.asoundrc 8. Put in it: # Encode AC3 - Directly on hardware pcm.Filter_A52Encode { type a52 bitrate 448 channels 6 card NVidia } # Rate Converter to 48kHz, needed for some applications pcm.a52 { type rate slave { pcm Filter_A52Encode rate 48000 } } 9. Change NVidia to your card's name from: cat /proc/asound/cards 10. sudo alsa reload 11. Make sure you do not have a ~/.pulse/default.pa or if you do, that it is using load-module module-udev-detect to load Alsa sinks not load-module module-alsa-sink ... 12. pulseaudio -k 13. pulseaudio -D I hope I didn't miss anything. This will give you sinks you can switch between in Sound Preferences for A52 and stereo that work even with libsdl (I tried Oolite). However, you cannot switch between A52 and stereo while the music is playing eg. in Rhythmbox - you will get that the resource is unavailable in the logs (at least, I did). It will resolve itself if you stop and restart the music. Cheers, Mike ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
Hi, Great news that AC3 passthrough is working. Well done! Are there any issues with AC3 encoding as I am using the A52 plugin from Pulseaudio (without your patch) and required the following hacks: a. A rate converter in asoundrc: # Rate Converter to 48kHz, needed for Pulseaudio it seems pcm.Filter_ RateConvert { type rate slave { pcm Filter_A52Encode rate 48000 } } b. A timeout=0 in default.pa load-module module-suspend-on-idle timeout=0 # timeout=0 required Even with these hacks, I found that sometimes I see: I: module.c: Unloading module-alsa-sink (index: #4). D: module-always-sink.c: Autoloading null-sink as no other sinks detected. After I see that, the sink disappears and cannot be selected any more in sound properties. 1. Does the ac3-iec958 profile resolve any of these issues? 2. Jack has ac3jack. What would be the pros and cons of doing the AC3 encoding in Pulseaudio instead of in Alsa? Cheers, Mike From: pl bossart bossart.nos...@gmail.com To: General PulseAudio Discussion pulseaudio-discuss@mail.0pointer.de Sent: Fri, 9 July, 2010 18:43:55 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support 1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or is someone actively looking at developing it? AC3 passthrough works (see patches at start of thread). That said there are still some opens and feedback is still welcome. I guess this will be part of Meego at some point, but since there''s nothing hw specific the discussion takes place in the open. 2. I think that encoding needs to be considered as part of the design ie. the possibility of AC3 or MP3 encoding before output to SPDIF. AC3 encoding can be done by selecting the relevant profile (ac3-iec958). The encoding takes place in alsa-lib a52 plugin. I initially removed these profiles but took some flak for it, apparently some people encode their multichannel streams prior to SPDIF transmission. I am afraid MP3 encoding in PulseAudio doesn't make sense, not supported either by SPDIF or HDMI. And for BT use cases, you might as well encode in SBC if you have PCM in the first place. Perhaps you're already past this point, but there is an Alsa utility iecset which returns (and can set) whether raw data or PCM is being passed to SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call the same function that utility does. iecset sets the AES0-3 bytes, but does not handle actual data formatting which is done by the gstreamer ac3iec958 element and by the alsa-lib iec958 plugin. For now I don't even bother to set these bits, they are so unreliable that receivers usually ignore them. Can someone point me to any design and API docs for Pulseaudio as I'm interested in learning where and how it connects to Alsa? No real docs. See the code in src/modules/alsa. Only took me a year to figure things out :-( ___ 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] {PATCH][RFC] AC3 passthrough support
On Sat, 2010-07-10 at 08:05 +, Michael Rans wrote: Even with these hacks, I found that sometimes I see: I: module.c: Unloading module-alsa-sink (index: #4). D: module-always-sink.c: Autoloading null-sink as no other sinks detected. After I see that, the sink disappears and cannot be selected any more in sound properties. 1. Does the ac3-iec958 profile resolve any of these issues? What's the ac3-iec958 profile? The iec958-ac3-surround-* mappings that currently exist in pulseaudio use the a52 alsa plugin, which may or may not work with Colin's patch[1]. (It didn't work for Colin.) 2. Jack has ac3jack. What would be the pros and cons of doing the AC3 encoding in Pulseaudio instead of in Alsa? I think it would make sense to do AC3 encoding in Pulseaudio, although in theory I don't see what difference it would make. Maybe it's somehow benefical to handle all the buffering inside Pulseaudio. If there are timing related bugs in the a52 plugin, as Colin seems to think there are, then it's also a matter of who volunteers first: a person who knows how to fix the a52 plugin, or a person who knows how to hack AC3 encoding support into Pulseaudio. [1] https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-June/007311.html -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
Hi, Thanks for your reply both to my message and the bug I posted. I tried Colin's patch, but it didn't work for me. I tried the following evil hack in alsa-sink.c: out_frames = snd_pcm_rewind(u-pcm_handle, (snd_pcm_uframes_t) in_frames); if (out_frames 0) { out_frames = -out_frames; } /*if ((out_frames = snd_pcm_rewind(u-pcm_handle, (snd_pcm_uframes_t) in_frames)) 0) { pa_log(snd_pcm_rewind() failed: %s, pa_alsa_strerror((int) out_frames)); if (try_recover(u, process_rewind, out_frames) 0) return -1; out_frames = 0; }*/ The sound played but very very fast in Oolite, so I would say it almost worked. I can't find any definition of snd_pcm_rewind() in the alsa-plugins source code. Does this function call through to a function in the plugins? I understand that there a function snd_pcm_hw_params_can_rewind which I would guess should return false for AC3 encoding - is this called by Pulseaudio? Cheers, Mike From: Tanu Kaskinen ta...@iki.fi To: pulseaudio-discuss@mail.0pointer.de Sent: Sat, 10 July, 2010 11:13:13 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support On Sat, 2010-07-10 at 08:05 +, Michael Rans wrote: Even with these hacks, I found that sometimes I see: I: module.c: Unloading module-alsa-sink (index: #4). D: module-always-sink.c: Autoloading null-sink as no other sinks detected. After I see that, the sink disappears and cannot be selected any more in sound properties. 1. Does the ac3-iec958 profile resolve any of these issues? What's the ac3-iec958 profile? The iec958-ac3-surround-* mappings that currently exist in pulseaudio use the a52 alsa plugin, which may or may not work with Colin's patch[1]. (It didn't work for Colin.) 2. Jack has ac3jack. What would be the pros and cons of doing the AC3 encoding in Pulseaudio instead of in Alsa? I think it would make sense to do AC3 encoding in Pulseaudio, although in theory I don't see what difference it would make. Maybe it's somehow benefical to handle all the buffering inside Pulseaudio. If there are timing related bugs in the a52 plugin, as Colin seems to think there are, then it's also a matter of who volunteers first: a person who knows how to fix the a52 plugin, or a person who knows how to hack AC3 encoding support into Pulseaudio. [1] https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-June/007311.html -- Tanu Kaskinen ___ 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] {PATCH][RFC] AC3 passthrough support
Hi, Further to my previous message, I tried: //pa_sink_set_max_rewind(u-sink, u-hwbuf_size); pa_sink_set_max_rewind(u-sink, 0); That seemed to fix it, although I fear it will break any other Alsa sinks. Is there a better way to implement this? Interestingly, I then no longer need tiemout=0 here: load-module module-suspend-on-idle But I still need to go via the rate converter to the a52 encoder in asoundrc. Cheers, Mike From: Michael Rans mcar...@yahoo.co.uk To: General PulseAudio Discussion pulseaudio-discuss@mail.0pointer.de Sent: Sat, 10 July, 2010 14:24:02 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support Hi, Thanks for your reply both to my message and the bug I posted. I tried Colin's patch, but it didn't work for me. I tried the following evil hack in alsa-sink.c: out_frames = snd_pcm_rewind(u-pcm_handle, (snd_pcm_uframes_t) in_frames); if (out_frames 0) { out_frames = -out_frames; } /*if ((out_frames = snd_pcm_rewind(u-pcm_handle, (snd_pcm_uframes_t) in_frames)) 0) { pa_log(snd_pcm_rewind() failed: %s, pa_alsa_strerror((int) out_frames)); if (try_recover(u, process_rewind, out_frames) 0) return -1; out_frames = 0; }*/ The sound played but very very fast in Oolite, so I would say it almost worked. I can't find any definition of snd_pcm_rewind() in the alsa-plugins source code. Does this function call through to a function in the plugins? I understand that there a function snd_pcm_hw_params_can_rewind which I would guess should return false for AC3 encoding - is this called by Pulseaudio? Cheers, Mike From: Tanu Kaskinen ta...@iki.fi To: pulseaudio-discuss@mail.0pointer.de Sent: Sat, 10 July, 2010 11:13:13 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support On Sat, 2010-07-10 at 08:05 +, Michael Rans wrote: Even with these hacks, I found that sometimes I see: I: module.c: Unloading module-alsa-sink (index: #4). D: module-always-sink.c: Autoloading null-sink as no other sinks detected. After I see that, the sink disappears and cannot be selected any more in sound properties. 1. Does the ac3-iec958 profile resolve any of these issues? What's the ac3-iec958 profile? The iec958-ac3-surround-* mappings that currently exist in pulseaudio use the a52 alsa plugin, which may or may not work with Colin's patch[1]. (It didn't work for Colin.) 2. Jack has ac3jack. What would be the pros and cons of doing the AC3 encoding in Pulseaudio instead of in Alsa? I think it would make sense to do AC3 encoding in Pulseaudio, although in theory I don't see what difference it would make. Maybe it's somehow benefical to handle all the buffering inside Pulseaudio. If there are timing related bugs in the a52 plugin, as Colin seems to think there are, then it's also a matter of who volunteers first: a person who knows how to fix the a52 plugin, or a person who knows how to hack AC3 encoding support into Pulseaudio. [1] https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-June/007311.html -- Tanu Kaskinen ___ 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] {PATCH][RFC] AC3 passthrough support
But I still need to go via the rate converter to the a52 encoder in asoundrc. Have you set the default sink frequency to 48kHz in /usr/etc/pulse/daemon.conf? This should handle resampling in PulseAudio. Still not clear why rewind doesn't work. - Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
My default.pa line has rate set at 48000 which I guess would take precedence: load-module module-alsa-sink device=Filter_RateConvert rate=48000 sink_properties=device.description=SPDIF sink_name=SPDIF) But just in case, I tried changing default-sample-rate = 48000 in daemon.conf. The error I got was: D: alsa-sink.c: snd_pcm_mmap_commit: Resource temporarily unavailable E: alsa-sink.c: Assertion 'err != -11' failed at modules/alsa/alsa-sink.c:395, function try_recover(). Aborting. BTW, I got the setup using a rate converter from here: http://www.johannes-bauer.com/linux/dolby/?menuid=3 where this chap says # Rate Converter to 48kHz, needed for some applications in his advanced set up. He didn't mention Pulseaudio, but it seems to do the trick. Regarding AC3 encoding in Pulseaudio - it would be better because at the moment switching between stereo and A52 is not possible (ie. I cannot have both these lines in default.pa: load-module module-alsa-sink device=Filter_RateConvert rate=48000 sink_properties=device.description=AC3 sink_name=AC3 load-module module-alsa-sink device=ALC889A_Digital sink_properties=device.description=SPDIF sink_name=SPDIF Presumably the SPDIF out is locked by one of them, then the other fails. With ac3 encoding in Pulseaudio, this would be switchable without editing any files. Cheers, Mike From: pl bossart bossart.nos...@gmail.com To: General PulseAudio Discussion pulseaudio-discuss@mail.0pointer.de Sent: Sat, 10 July, 2010 16:12:26 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support But I still need to go via the rate converter to the a52 encoder in asoundrc. Have you set the default sink frequency to 48kHz in /usr/etc/pulse/daemon.conf? This should handle resampling in PulseAudio. Still not clear why rewind doesn't work. - Pierre ___ 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] {PATCH][RFC] AC3 passthrough support
On Thu, 2010-07-08 at 10:06 -0500, pl bossart wrote: First this passthrough mode is only valid for S/PDIF and HDMI outputs. In both cases, the receiver may or may not support encoded content, and in the SPDIF case you have no way of querying what the receiver capabilities are. You absolutely do not want to send passthrough streams without making sure the configuration makes sense. So somehow user interaction is required to explicitly tell PulseAudio the receiver supports AC3/DTS passthrough. To be more self-explanatory we should have a check-box in pavucontrol than a different profile. I really did not want to switch configurations depending on the type of content, ALSA/iec958 accepts both. I agree that it's not really a good solution to require the user to change the card profile manually to enable passthrough via spdif. But as I said, a separate module could take care switching between the profiles as needed. Having thought this for a while, the only thing that really irritates me in your design is that the semantics of the PA_SINK_PASSTHROUGH become messy: the flag says that in addition to normal PCM streams, this sink supports also passthrough streams, except at times when there already exist PCM streams, and btw, while a passthrough stream is playing, PCM streams cease to be supported. I guess that's not a very practical problem, though. Ah, but now a better argument popped into my mind. If a sink can enter the passthrough mode on the fly, then that has a consequence that affects any application that is interested in sink volumes: whether a sink has adjustable volume can change any time. That's not very nice. Previously I claimed that since the the stream is compressed, we inevitably will have to extend the code in pa_bytes_to_usec(), but I realized now that as long as we pretend that the stream really is a regular stereo stream, all calculations end up correct. Now the only problem is that the user is given sort of wrong information, but I don't think that's a big problem, so I agree with your approach of leaving the sample spec alone and relying only on the sink and sink input flags. The code can be improved later, if needed. About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958. First, non-audio is not really correct, because the data is still audio, but the main issue is the iec958 part. There can potentially be many formats that need to be passed through unchanged, so in the future there could be need for PA_STREAM_NONAUDIO_FOO and PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put the format information - the format should have its own variable. Until new formats are introduced, you can still rely on a single flag, though. I propose that you just rename the flags: - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH, - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH. I really don't think there are that many formats. The only use cases I can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power audio. Adding flags on the sinks is no big deal. Even if we have only two formats, iec958 and mp3, I don't see why the sink flags would the proper place to specify the format. I believe most of the passthrough related code is only interested in the fact that the stream data shall not be touched. If there are multiple flags for all the different passthrough formats, then all that code will have to check for two flags instead of one. The real problem is at the pa_stream level. We don't want to have to extend the protocol several times. I added a flag but if we have more than one format we will need more room for subtypes. We should probably extend the buff_attr attributes for this? I haven't though about this much, but I have a feeling that more complex formats (like mp3) are going to need more metadata than currently available (stuff like bitrate, CBR vs VBR etc.), and if support for other codecs is going to be needed in the future, the set of metadata items might vary between codecs. I wouldn't care about all that complex stuff before it's implemented - in other words, I don't see it as a big problem if the protocol will have to be extended multiple times for different codecs. (Of course it would be nice to avoid that, but I wouldn't trust at least myself to get it right at first try without actually implementing the mp3 passthrough functionality at the same time.) I think the most natural place for input compatibility checking is in the sink object. At least it achieves better encapsulation, because then you don't need to poke the sink's private-ish data from outside the sink object. That makes future changes easier to do. I disagree. I think you want a common logic in the core to make sure that things work the same way no matter what configuration you use. And its make sure we don't have to modify
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
I agree that it's not really a good solution to require the user to change the card profile manually to enable passthrough via spdif. But as I said, a separate module could take care switching between the profiles as needed. I don't understand your proposal. What do you mean by separate 'module' and how would this work with the current mixer profiles? Having thought this for a while, the only thing that really irritates me in your design is that the semantics of the PA_SINK_PASSTHROUGH become messy: the flag says that in addition to normal PCM streams, this sink supports also passthrough streams, except at times when there already exist PCM streams, and btw, while a passthrough stream is playing, PCM streams cease to be supported. I guess that's not a very practical problem, though. It's not really my design, it's just how SPDIF/HDMI work... Ah, but now a better argument popped into my mind. If a sink can enter the passthrough mode on the fly, then that has a consequence that affects any application that is interested in sink volumes: whether a sink has adjustable volume can change any time. That's not very nice. Duh? If we fixed the volume stuff so that that the volume control app disables its sliders when passthrough AC3 is enabled, what would be the issue. This is how VLC works, when you stream AC3 data the volume control is no longer enabled. Even if we have only two formats, iec958 and mp3, I don't see why the sink flags would the proper place to specify the format. I believe most of the passthrough related code is only interested in the fact that the stream data shall not be touched. If there are multiple flags for all the different passthrough formats, then all that code will have to check for two flags instead of one. I guess we could have a two-step process, where you first detect if the sink and sink-input have support for PASSTHROUGH, and then in a second step you verify that the 'subtype' (iec958 or mp3) is compatible. The logic for rejecting connections is the same... You only need one last step to make sure types are compatible. There would of course be a standard implementation for sinks that don't do any strange stuff. I thought individual sink implementations could choose to amend the standard logic, but actually I'm not sure how it could be done without duplicating code. Giving it a second thought, the can this sink input be connected to this sink question can be thought equally well as a method of sinks or sink inputs, or even as a plain old independent function. So, doing it like you do it in your patch is fine by me (just don't use iec958 where the logic isn't really bound to the exact format). As I said above, we can have a first pass implemented in the core that checks things are fine, then a second pass implemented by sinks who support passthrough mode to check fine-grained compatibility. The NOVOLUME flags can be exported to clients, so they can choose to not show any volume controls. Legacy clients should get the PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or sinks that have the NOVOLUME flag. Yes the volume needs more work. I don't really understand all this code through, so for now I disabled the set-volume() routines without notifying the client. You end-up in the situation where pavucontrol can change the volume but nothing happens, this is not user-friendly. Is this NOVOLUME flag an existing one, or something that would need to be added? It needs to be added. There's already a detection in the mixer code that the hw_volume is available or not. Maybe we can use this as well. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
Hi, 1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or is someone actively looking at developing it? 2. I think that encoding needs to be considered as part of the design ie. the possibility of AC3 or MP3 encoding before output to SPDIF. Perhaps you're already past this point, but there is an Alsa utility iecset which returns (and can set) whether raw data or PCM is being passed to SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call the same function that utility does. Can someone point me to any design and API docs for Pulseaudio as I'm interested in learning where and how it connects to Alsa? Cheers, Mike From: pl bossart bossart.nos...@gmail.com To: General PulseAudio Discussion pulseaudio-discuss@mail.0pointer.de Sent: Fri, 9 July, 2010 16:51:21 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support I agree that it's not really a good solution to require the user to change the card profile manually to enable passthrough via spdif. But as I said, a separate module could take care switching between the profiles as needed. I don't understand your proposal. What do you mean by separate 'module' and how would this work with the current mixer profiles? Having thought this for a while, the only thing that really irritates me in your design is that the semantics of the PA_SINK_PASSTHROUGH become messy: the flag says that in addition to normal PCM streams, this sink supports also passthrough streams, except at times when there already exist PCM streams, and btw, while a passthrough stream is playing, PCM streams cease to be supported. I guess that's not a very practical problem, though. It's not really my design, it's just how SPDIF/HDMI work... Ah, but now a better argument popped into my mind. If a sink can enter the passthrough mode on the fly, then that has a consequence that affects any application that is interested in sink volumes: whether a sink has adjustable volume can change any time. That's not very nice. Duh? If we fixed the volume stuff so that that the volume control app disables its sliders when passthrough AC3 is enabled, what would be the issue. This is how VLC works, when you stream AC3 data the volume control is no longer enabled. Even if we have only two formats, iec958 and mp3, I don't see why the sink flags would the proper place to specify the format. I believe most of the passthrough related code is only interested in the fact that the stream data shall not be touched. If there are multiple flags for all the different passthrough formats, then all that code will have to check for two flags instead of one. I guess we could have a two-step process, where you first detect if the sink and sink-input have support for PASSTHROUGH, and then in a second step you verify that the 'subtype' (iec958 or mp3) is compatible. The logic for rejecting connections is the same... You only need one last step to make sure types are compatible. There would of course be a standard implementation for sinks that don't do any strange stuff. I thought individual sink implementations could choose to amend the standard logic, but actually I'm not sure how it could be done without duplicating code. Giving it a second thought, the can this sink input be connected to this sink question can be thought equally well as a method of sinks or sink inputs, or even as a plain old independent function. So, doing it like you do it in your patch is fine by me (just don't use iec958 where the logic isn't really bound to the exact format). As I said above, we can have a first pass implemented in the core that checks things are fine, then a second pass implemented by sinks who support passthrough mode to check fine-grained compatibility. The NOVOLUME flags can be exported to clients, so they can choose to not show any volume controls. Legacy clients should get the PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or sinks that have the NOVOLUME flag. Yes the volume needs more work. I don't really understand all this code through, so for now I disabled the set-volume() routines without notifying the client. You end-up in the situation where pavucontrol can change the volume but nothing happens, this is not user-friendly. Is this NOVOLUME flag an existing one, or something that would need to be added? It needs to be added. There's already a detection in the mixer code that the hw_volume is available or not. Maybe we can use this as well. ___ 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] {PATCH][RFC] AC3 passthrough support
1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or is someone actively looking at developing it? AC3 passthrough works (see patches at start of thread). That said there are still some opens and feedback is still welcome. I guess this will be part of Meego at some point, but since there''s nothing hw specific the discussion takes place in the open. 2. I think that encoding needs to be considered as part of the design ie. the possibility of AC3 or MP3 encoding before output to SPDIF. AC3 encoding can be done by selecting the relevant profile (ac3-iec958). The encoding takes place in alsa-lib a52 plugin. I initially removed these profiles but took some flak for it, apparently some people encode their multichannel streams prior to SPDIF transmission. I am afraid MP3 encoding in PulseAudio doesn't make sense, not supported either by SPDIF or HDMI. And for BT use cases, you might as well encode in SBC if you have PCM in the first place. Perhaps you're already past this point, but there is an Alsa utility iecset which returns (and can set) whether raw data or PCM is being passed to SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call the same function that utility does. iecset sets the AES0-3 bytes, but does not handle actual data formatting which is done by the gstreamer ac3iec958 element and by the alsa-lib iec958 plugin. For now I don't even bother to set these bits, they are so unreliable that receivers usually ignore them. Can someone point me to any design and API docs for Pulseaudio as I'm interested in learning where and how it connects to Alsa? No real docs. See the code in src/modules/alsa. Only took me a year to figure things out :-( ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
On Fri, 2010-07-09 at 10:51 -0500, pl bossart wrote: I agree that it's not really a good solution to require the user to change the card profile manually to enable passthrough via spdif. But as I said, a separate module could take care switching between the profiles as needed. I don't understand your proposal. What do you mean by separate 'module' and how would this work with the current mixer profiles? PA_CORE_HOOK_SINK_INPUT_NEW is fired at the beginning of pa_sink_input_new(). A module can connect to that hook and detect that ah, data-flags contains PA_SINK_INPUT_PASSTHROUGH, and data-sink is NULL, I'll make sure that the passthrough sink is available. Configuring (automatically) such module would need some extensions to the card profile code so that this new module could figure out what needs to be done in order to make sure that the passthrough sink is available. My feeling is/was that it's probably doable without too much difficulty, and that's about as far as I thought about it. Now, what if data-sink is not NULL? That means that when the client created the stream, the correct profile was already activated. Or, alternatively, data-sink points to some ghost of a currently non-existing sink that can, however, be made real automatically somehow. This latter scenario refers to functionality that doesn't currently exist. Implementing such functionality would require big changes to a lot of stuff. I'm starting to like your approach more and more. Having thought this for a while, the only thing that really irritates me in your design is that the semantics of the PA_SINK_PASSTHROUGH become messy: the flag says that in addition to normal PCM streams, this sink supports also passthrough streams, except at times when there already exist PCM streams, and btw, while a passthrough stream is playing, PCM streams cease to be supported. I guess that's not a very practical problem, though. It's not really my design, it's just how SPDIF/HDMI work... Well, when defining the semantics of PA_SINK_PASSTHROUGH you're free to choose between combined PCM and passthrough or passthrough only. Either can be made to work with spdif/hdmi. And I think it's not really specific to spdif/hdmi - both semantics can be used with any passthrough sink. For example, using your semantics, an A2DP sink can switch between real-time SBC encoding and passthrough MP3 on the fly similarly how an spdif sink can change between PCM and passthrough operation. The only case where the combined semantics wouldn't work is when the sink just plain can't work in any other mode than passthrough. I think it's quite improbable that we'll ever see such sink. Ah, but now a better argument popped into my mind. If a sink can enter the passthrough mode on the fly, then that has a consequence that affects any application that is interested in sink volumes: whether a sink has adjustable volume can change any time. That's not very nice. Duh? If we fixed the volume stuff so that that the volume control app disables its sliders when passthrough AC3 is enabled, what would be the issue. This is how VLC works, when you stream AC3 data the volume control is no longer enabled. What I had in mind was that if changing between PCM and passthrough modes would require changing profiles, then clients wouldn't need to be prepared to disable and enable volume control for a sink on the fly. They would only need to check whether a sink has volume when they initially create the widget for the sink. If volume can be disabled on the fly, that pushes more complexity to the clients, which is not good. But actually I think we'll have to do this, since the profile-switching module seems impractical. It seems like all my ideas were crap :) Even if we have only two formats, iec958 and mp3, I don't see why the sink flags would the proper place to specify the format. I believe most of the passthrough related code is only interested in the fact that the stream data shall not be touched. If there are multiple flags for all the different passthrough formats, then all that code will have to check for two flags instead of one. I guess we could have a two-step process, where you first detect if the sink and sink-input have support for PASSTHROUGH, and then in a second step you verify that the 'subtype' (iec958 or mp3) is compatible. The logic for rejecting connections is the same... You only need one last step to make sure types are compatible. There would of course be a standard implementation for sinks that don't do any strange stuff. I thought individual sink implementations could choose to amend the standard logic, but actually I'm not sure how it could be done without duplicating code. Giving it a second thought, the can this sink input be connected to this sink question can be thought equally well as a method of sinks or sink inputs, or even as a plain old independent function. So, doing it like you do
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
On Wed, 2010-07-07 at 19:37 -0500, pl bossart wrote: here's a first work-in-progress set of patches. I managed to route iec958 formatted data through PulseAudio, works fine but there's still a lot to do. Sounds very good! Thanks for your work! There's some logic to prevent silly connections but still allow for the same use cases as before: you can still mix and play PCM streams on a passthrough output, however you cannot connect nonaudio data to a regular sink, and likewise if a sink has already a connection you can only connect if both the existing inputs and the new one are PCM. Volume control is disabled only when a nonaudio stream is connected. So, do you think that if the card profile is set to Digital Passthrough (IEC958), the sink should still accept normal PCM streams? I don't think that's a good idea. You apparently do, and I'm not sure I'm able to convince you otherwise, but I'll try. In your design the PA_SINK_PASSTHROUGH flag means that the sink can be used both for exclusive passthrough streams and for normal streams. Are you sure we can keep that promise for all future passthrough sinks too? It would be cleaner to have strict separation between passthrough sinks and non-passthrough sinks. I admit that your approach makes it much easier for the user to switch between passthrough and non-passthrough content, but that effect could also be achieved with a separate module that changes the card profile whenever a passthrough stream is being created. I still have to do some work on sample-rate and channel map adaptation, but comments are welcome at this point. Ok, I'll comment. +[Element IEC958] +switch = mute What if this element doesn't exist? Or is it guaranteed to exist? If it doesn't exist, then PA will use software muting, i.e. feeding zeroes to the device. I don't think that's good. A stream of zeroes is not a valid iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and streams. Or is alsa capable of switching between passthrough and PCM modes on the fly just by inspecting the data? @@ -163,6 +163,7 @@ struct pa_alsa_path { pa_bool_t has_mute:1; pa_bool_t has_volume:1; pa_bool_t has_dB:1; +pa_bool_t is_passthrough:1; long min_volume, max_volume; double min_dB, max_dB; is_passthrough doesn't seem to be set anywhere. Other comments: Previously I claimed that since the the stream is compressed, we inevitably will have to extend the code in pa_bytes_to_usec(), but I realized now that as long as we pretend that the stream really is a regular stereo stream, all calculations end up correct. Now the only problem is that the user is given sort of wrong information, but I don't think that's a big problem, so I agree with your approach of leaving the sample spec alone and relying only on the sink and sink input flags. The code can be improved later, if needed. About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958. First, non-audio is not really correct, because the data is still audio, but the main issue is the iec958 part. There can potentially be many formats that need to be passed through unchanged, so in the future there could be need for PA_STREAM_NONAUDIO_FOO and PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put the format information - the format should have its own variable. Until new formats are introduced, you can still rely on a single flag, though. I propose that you just rename the flags: - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH, - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH. You can put in the client documentation that if the PA_STREAM_PASSTHROUGH flag is specified, the stream is currently assumed to be iec958 formatted, and the sample spec must be stereo s16le with sample rate of 32000, 44100 or 48000 Hz. In the future there may be more options. I still hold on to a couple of my previous suggestions: create pa_sink_accept_input() and use NOVOLUME flags in sinks and sink inputs. I think the most natural place for input compatibility checking is in the sink object. At least it achieves better encapsulation, because then you don't need to poke the sink's private-ish data from outside the sink object. That makes future changes easier to do. The NOVOLUME flags can be exported to clients, so they can choose to not show any volume controls. Legacy clients should get the PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or sinks that have the NOVOLUME flag. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
In your design the PA_SINK_PASSTHROUGH flag means that the sink can be used both for exclusive passthrough streams and for normal streams. Are you sure we can keep that promise for all future passthrough sinks too? It would be cleaner to have strict separation between passthrough sinks and non-passthrough sinks. I admit that your approach makes it much easier for the user to switch between passthrough and non-passthrough content, but that effect could also be achieved with a separate module that changes the card profile whenever a passthrough stream is being created. First this passthrough mode is only valid for S/PDIF and HDMI outputs. In both cases, the receiver may or may not support encoded content, and in the SPDIF case you have no way of querying what the receiver capabilities are. You absolutely do not want to send passthrough streams without making sure the configuration makes sense. So somehow user interaction is required to explicitly tell PulseAudio the receiver supports AC3/DTS passthrough. To be more self-explanatory we should have a check-box in pavucontrol than a different profile. I really did not want to switch configurations depending on the type of content, ALSA/iec958 accepts both. +[Element IEC958] +switch = mute What if this element doesn't exist? Or is it guaranteed to exist? If it doesn't exist, then PA will use software muting, i.e. feeding zeroes to the device. I don't think that's good. A stream of zeroes is not a valid iec958 stream, AFAIK. I think we need a NOMUTE flag for sinks and streams. Or is alsa capable of switching between passthrough and PCM modes on the fly just by inspecting the data? The IEC958 switch exists on most ALSA cards, I didn't really look into cases where this would not be supported. Sending zeroes is fine I guess, the receiver will understand the samples are not valid and go to a mute mode as well. There's currently a limitation that this control is locked, but Takashi agrees this could be removed and it'll be fixed. @@ -163,6 +163,7 @@ struct pa_alsa_path { pa_bool_t has_mute:1; pa_bool_t has_volume:1; pa_bool_t has_dB:1; + pa_bool_t is_passthrough:1; long min_volume, max_volume; double min_dB, max_dB; is_passthrough doesn't seem to be set anywhere. Right. I initially wanted to add a statement in the profile configuration, but I ended-up matching the path name to instead. Ideally we should extend Lennart's description rather than match hard-coded names, but this is beyond my programming abilities. Previously I claimed that since the the stream is compressed, we inevitably will have to extend the code in pa_bytes_to_usec(), but I realized now that as long as we pretend that the stream really is a regular stereo stream, all calculations end up correct. Now the only problem is that the user is given sort of wrong information, but I don't think that's a big problem, so I agree with your approach of leaving the sample spec alone and relying only on the sink and sink input flags. The code can be improved later, if needed. About flag names: I would not use names like PA_STREAM_NONAUDIO_IEC958. First, non-audio is not really correct, because the data is still audio, but the main issue is the iec958 part. There can potentially be many formats that need to be passed through unchanged, so in the future there could be need for PA_STREAM_NONAUDIO_FOO and PA_STREAM_NONAUDIO_BAR. At that point flags aren't the best place to put the format information - the format should have its own variable. Until new formats are introduced, you can still rely on a single flag, though. I propose that you just rename the flags: - PA_STREAM_NONAUDIO_IEC958 to PA_STREAM_PASSTHROUGH, - PA_SINK_INPUT_NONAUDIO_IEC958 to PA_SINK_INPUT_PASSTHROUGH and - PA_SINK_PASSTHROUGH_IEC958 to PA_SINK_PASSTHROUGH. I really don't think there are that many formats. The only use cases I can think of are AC3/DTS a la iec958, or MP3 for BT headsets/low-power audio. Adding flags on the sinks is no big deal. The real problem is at the pa_stream level. We don't want to have to extend the protocol several times. I added a flag but if we have more than one format we will need more room for subtypes. We should probably extend the buff_attr attributes for this? As you have probably read, the addition of this flag breaks the protocol, and I am really not religious on names/types. I will go with the majority. Lennart, Colin, your guidance would be more than welcome here. This is why I posted the patches early to gather feedback. I think the most natural place for input compatibility checking is in the sink object. At least it achieves better encapsulation, because then you don't need to poke the sink's private-ish data from outside the sink object. That makes future changes easier to do. I disagree. I think you want a common logic in the core to make sure that things work the same way no matter what configuration you use.
[pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
here's a first work-in-progress set of patches. I managed to route iec958 formatted data through PulseAudio, works fine but there's still a lot to do. As discussed on the mailing list, I added a new flag to pa_stream connections, and also added a flag for the sink in case it can handle passthrough data. There's some logic to prevent silly connections but still allow for the same use cases as before: you can still mix and play PCM streams on a passthrough output, however you cannot connect nonaudio data to a regular sink, and likewise if a sink has already a connection you can only connect if both the existing inputs and the new one are PCM. Volume control is disabled only when a nonaudio stream is connected. You can give it a try by setting the 'Passthrough' configuration in pavucontrol and the following command line gst-launch filesrc location=file.ac3 ! ac3iec958 raw-audio=true ! pulsesink (note that pulsesink needs to be extended to handle the x-iec958 caps and set the NONAUDIO_IEC958 flag when needed, the mixing logic will not work with pulsesink). I still have to do some work on sample-rate and channel map adaptation, but comments are welcome at this point. Cheers - Pierre 0001-alsa-fix-mixer-profiles-add-passthrough-config.patch Description: Binary data 0002-AC3-passthrough-support.patch Description: Binary data ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss