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.
