Re: [pulseaudio-discuss] review+pull-request: Passthrough support
On 04/19/2011 02:03 PM, pl bossart wrote: I finally managed to figure out why eac3 wouldn't work in passthrough mode. Apparently my HDMI receiver will only lock on eac3 data if the AES0 control is set to 0x06 (non-audio, ie iec61937). ffmpeg -acodec copy -i csi_miami_5.1_256_spx.eac3 -f spdif outfile.pcm aplay -Dhdmi:AES0=0x6 -fs16 -c2 -r192000 outfile.pcm the same file plays well through pulseaudio if I modifed default.conf to [Mapping hdmi-stereo] device-strings = hdmi:%f,AES0=0x06 channel-map = left,right priority = 4 direction = output Somehow we need to find a way to set this AES0 byte when opening the iec958 or hdmi device in the passthrough code, and reset it back to 0x04 for PCM playback (should be fairly easy to do by looking at the code of iecset in alsa-utils). Beats me why this was not needed for plain ac3, but setting the audio bit is actually the correct thing to do. So far I haven't been able to get anything except stereo working with passthrough. It seems to me that selecting multiple channels in passthrough mode would be very similar to the necessary AES0 changes, so maybe we can get that fixed too. I've basically hit a wall by only being able to passthrough 192khz stereo. When the passthrough data rate exceeds the available rate, my code clips the data packets. Which seems to work OK when the excess is maybe 200 bytes or so. On some HD DTS I'm clipping more like 2K per packet which results in some very nasty sounds emanating from the speakers. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
Arun, I've been trying to get higher bit rates to passthrough with no luck. Is setting the channel count supported with passthrough (yet)? It seems that 384k sample rates aren't supported directly in alsa, I did some patching to no avail yet. In any case if the channel count can be specified with passthrough the following should work. paplay --raw --channels=2 --rate=192000 --passthrough File.dts.spdif192khz ( this works). paplay --raw --channels=4 --rate=192000 --passthrough File.dts.spdif384khz ( this fails). To passthrough dolby true-hd it looks like it'll be necessary for more than two channels to work. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On 03/24/11 18:58, Dark Shadow wrote: On Thu, Mar 24, 2011 at 10:50 AM, Anssi Hannulaanssi.hann...@iki.fi wrote: On 24.03.2011 16:18, pl bossart wrote: It seems that 384k sample rates aren't supported directly in alsa, I did some patching to no avail yet. In any case if the channel count can be specified with passthrough the following should work. paplay --raw --channels=2 --rate=192000 --passthrough File.dts.spdif192khz ( this works). paplay --raw --channels=4 --rate=192000 --passthrough File.dts.spdif384khz ( this fails). To passthrough dolby true-hd it looks like it'll be necessary for more than two channels to work. There was a thread on dts-hd in alsa-devel at some point. Anssi (cc:ed) contributed some patches for HDMI and provided the information below on ffmpeg configurations. You may want to try at the alsa level before trying with pulseaudio to make sure your setup is correct. I tend to believe you have to go for 8ch @ 192kHz to make this work based on my limited understanding of HBR. Indeed for HBR you need to always specify 8 channels and use rate to control the final rate (i.e. you either use normal 2 channel passthrough or HBR 8 channel passthrough). For example to passthrough the abovementioned 384 kHz stream you need to use 8 channels and rate of 96000. However, I think 384kHz DTS bitstream is generally *not* supported by A/V receivers, so you probably want to use 768kHz (8 channels, 192kHz). (note: I haven't tested whether HBR works with pulseaudio or not) The DTS-HD part is not merged yet (patch is in ffmpeg-devel@), but the TrueHD and E-AC-3 support is already there in ffmpeg trunk. The ffmpeg commandline to use is: ffmpeg -i input.file -f spdif output.spdif For DTS-HD files, to get full passthrough (i.e. not only core), a -dtshd_rate parameter is needed, which sets the output IEC958 rate. ffmpeg -i input.file -f spdif -dtshd_rate 192000 output.spdif ffmpeg -i input.file -f spdif -dtshd_rate 768000 output.spdif 192000Hz is enough for streams that have a bitrate below 6.144Mbps, which means all DTS-HD High Resolution Audio files and even many of the DTS-HD Master Audio (the latter are lossless VBR). To play the spdif files back, I use aplay -D hdmi:CARD=$CARDNAME,DEV=$DEVICENUM,AES0=0x06 -c $CHANCOUNT -r $RATE file.spdif - replacing $CARDNAME with the card name - replacing $DEVICENUM with 0..3 depending on card and hdmi port (for non-zero DEVICENUM you'll need a patch from alsa git: http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=e6d5dcf1f625984605d362338d71162de45a6c60 ) - set $CHANCOUNT and $RATE as per below - rate 192000 and channels 2 for IEC958 rate 192 kHz (for e.g. 48 kHz E-AC-3, and DTS-HD when the IEC958 rate was set to 192000 in ffmpeg) - rate 192000 and channels 8 for IEC958 rate 768 kHz (for most TrueHD files, and for DTS-HD when the rate was set to 768000) - note that having the 0x02 bit (non-pcm) set in AES0 is mandatory when $CHANCOUNT is larger than 2, as ALSA uses it to determine whether to use HBR or not. The additional 0x04 (non-copyright) I use above is not mandatory, but is the alsa default so I kept it. -- Anssi Hannula ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss Would anyone know where I could get a hold of some DTS-HD samples in 192Khz and 384kHz for testing? You can extract the dts-hd tracks from your mkv's with mkvextract. You can make them with spdifer (part of AudioFilter). ___ 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] [WIP] Passthrough support
On 03/24/11 19:35, Dark Shadow wrote: On Thu, Mar 24, 2011 at 7:19 PM, Kelly Anderson ke...@silka.with-linux.com wrote: On 03/24/11 18:58, Dark Shadow wrote: On Thu, Mar 24, 2011 at 10:50 AM, Anssi Hannulaanssi.hann...@iki.fi wrote: On 24.03.2011 16:18, pl bossart wrote: It seems that 384k sample rates aren't supported directly in alsa, I did some patching to no avail yet. In any case if the channel count can be specified with passthrough the following should work. paplay --raw --channels=2 --rate=192000 --passthrough File.dts.spdif192khz ( this works). paplay --raw --channels=4 --rate=192000 --passthrough File.dts.spdif384khz ( this fails). To passthrough dolby true-hd it looks like it'll be necessary for more than two channels to work. There was a thread on dts-hd in alsa-devel at some point. Anssi (cc:ed) contributed some patches for HDMI and provided the information below on ffmpeg configurations. You may want to try at the alsa level before trying with pulseaudio to make sure your setup is correct. I tend to believe you have to go for 8ch @ 192kHz to make this work based on my limited understanding of HBR. Indeed for HBR you need to always specify 8 channels and use rate to control the final rate (i.e. you either use normal 2 channel passthrough or HBR 8 channel passthrough). For example to passthrough the abovementioned 384 kHz stream you need to use 8 channels and rate of 96000. However, I think 384kHz DTS bitstream is generally *not* supported by A/V receivers, so you probably want to use 768kHz (8 channels, 192kHz). (note: I haven't tested whether HBR works with pulseaudio or not) The DTS-HD part is not merged yet (patch is in ffmpeg-devel@), but the TrueHD and E-AC-3 support is already there in ffmpeg trunk. The ffmpeg commandline to use is: ffmpeg -i input.file -f spdif output.spdif For DTS-HD files, to get full passthrough (i.e. not only core), a -dtshd_rate parameter is needed, which sets the output IEC958 rate. ffmpeg -i input.file -f spdif -dtshd_rate 192000 output.spdif ffmpeg -i input.file -f spdif -dtshd_rate 768000 output.spdif 192000Hz is enough for streams that have a bitrate below 6.144Mbps, which means all DTS-HD High Resolution Audio files and even many of the DTS-HD Master Audio (the latter are lossless VBR). To play the spdif files back, I use aplay -D hdmi:CARD=$CARDNAME,DEV=$DEVICENUM,AES0=0x06 -c $CHANCOUNT -r $RATE file.spdif - replacing $CARDNAME with the card name - replacing $DEVICENUM with 0..3 depending on card and hdmi port (for non-zero DEVICENUM you'll need a patch from alsa git: http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=e6d5dcf1f625984605d362338d71162de45a6c60 ) - set $CHANCOUNT and $RATE as per below - rate 192000 and channels 2 for IEC958 rate 192 kHz (for e.g. 48 kHz E-AC-3, and DTS-HD when the IEC958 rate was set to 192000 in ffmpeg) - rate 192000 and channels 8 for IEC958 rate 768 kHz (for most TrueHD files, and for DTS-HD when the rate was set to 768000) - note that having the 0x02 bit (non-pcm) set in AES0 is mandatory when $CHANCOUNT is larger than 2, as ALSA uses it to determine whether to use HBR or not. The additional 0x04 (non-copyright) I use above is not mandatory, but is the alsa default so I kept it. -- Anssi Hannula ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss Would anyone know where I could get a hold of some DTS-HD samples in 192Khz and 384kHz for testing? You can extract the dts-hd tracks from your mkv's with mkvextract. You can make them with spdifer (part of AudioFilter). ___ 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 Unless I am missing something all the movies I play say 48kHz on my receivers OSD when played through my PS3 so I thought that was the best they have, and higher was not used on average Blu-Ray's. The original samples are taken at 48khz and then compressed into dts or dts-hd. AudioFilter is muxing the dts/dts-hd packets into zero padded packets that contain the dts/dts-hd stream. A typical dts-hd stream is going to have packets around the 8k size. If it is muxed at 192khz packets that exceed it's size limit will be clipped. In my experience I was seeing maybe 200 bytes dropped on some packets. Now if you mux it at 384khz you effectively double the size of the packets that can be sent to the receiver and you don't have to resort to clipping. In a nutshell the 192khz and 384khz rates are spdif muxed rates not the original sample rate. ___ pulseaudio-discuss mailing list pulseaudio
Re: [pulseaudio-discuss] Pulseaudio passthrough branch doesn't read /etc/pulse/default.pa
On 03/23/11 17:20, Colin Guthrie wrote: 'Twas brillig, and Maarten Bosmans at 23/03/11 18:36 did gyre and gimble: 2011/3/21 Dark Shadowshadowofdarkn...@gmail.com: On Sun, Mar 20, 2011 at 5:58 PM, Dark Shadowshadowofdarkn...@gmail.com wrote: I have successfully bitstreamed DTS-HD from xbmc through PA but in using the passthrough git branch it doesn't read that config file which causes problems for me forcing a sink. How can I fix this since I have to kill pulseaudio then restart it with pulseaudio --load=module-alsa-sink device=hdmi:1,3 to get hdmi audio working I am running Ubuntu 11.04 Alpha. I figured it out, I copied default.pa into ~/.pulse and it works now. Not preferential in a multi-user environment but it is fine for now. With the feature of lasting through a distro upgrade. That's a workaround, but pulse still should read the system-wide startup script (note that that is different from the config file) What does pulseaudio --dump-config give? Am I missing something here... default.pa is the startup script and if it exists in ~/.pulse it overrides the one in /etc/pulse/. The system-wide one won't be read at all. Even with the daemon.conf file, the same logic is true (even if it would in theory be possible to read both, with the local file overriding the system wide one on a setting-by-setting basis) Perhaps I'm misunderstanding tho' Col I'm pretty sure what he means is that daemon.conf isn't being read from /etc/pulse when he doesn't have a ~.pulse/daemon.conf. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] XBMC - PulseAudio - passthrough ready for testing
Not sure how many PulseAudio developers are interested, but here's my post in the Xbmc developer's forum. OK, I've been burnin the midnight oil so I'm ready for others to test the results. Download/build/install in order. git://git.collabora.co.uk/git/user/arun/pulseaudio.git git://github.com/cbxbiker61/audiofilter.git git://github.com/cbxbiker61/xbmc.git Configure xbmc with appropriate devices selected in System Settings/Audio, pulse audio devices show up with (pulse) extension. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On 03/16/11 10:48, Arun Raghavan wrote: On Wed, 2011-03-16 at 11:19 +0530, Arun Raghavan wrote: [...] It will work, but not with paplay, only with the extended API when you create a non-PCM stream. I will rationalise the check for passthrough sink inputs in a bit, but for now, could you change the checks (there I've pushed a more comprehensive fix, so you shouldn't need to change that line and using paplay should work for you. -- Arun Arun, Hey, I just got around to testing without the following patch. It doesn't work. I also didn't see any recent checkins in the passthrough tree that would seem to affect this. Is it possible the fix didn't get pushed? --- ./src/modules/alsa/alsa-sink.c.orig 2011-03-16 01:17:02.061953124 -0600 +++ ./src/modules/alsa/alsa-sink.c 2011-03-16 01:19:07.492460278 -0600 @@ -1058,7 +1058,7 @@ static int sink_process_msg(pa_msgobject pa_sink_input *i = PA_SINK_INPUT(data); int r = 0; -if (PA_LIKELY(pa_format_info_is_pcm(i-format))) +if (PA_LIKELY(!(i-flags PA_SINK_INPUT_PASSTHROUGH)) ) break; u-old_rate = u-sink-sample_spec.rate; @@ -1084,7 +1084,7 @@ static int sink_process_msg(pa_msgobject pa_sink_input *i = PA_SINK_INPUT(data); int r = 0; -if (PA_LIKELY(pa_format_info_is_pcm(i-format))) +if (PA_LIKELY(!(i-flags PA_SINK_INPUT_PASSTHROUGH)) ) break; /* Passthrough format, see if we need to reset sink sample rate */ ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio xbmc passthrough success
Good news :) I've just watched District 9 and Master and Commander in full dts-hd. A few minor glitches (a couple of pops, I think it might be buffer underruns), other than that it worked great! One thing I did notice with Master and Commander was that with standard dts the dialog was not nearly as clear as it was with dts-hd. dts-hd has about 4 times the bandwidth. I'll be putting up the newer code sometime tomorrow. I've been working pretty long hours on it and now I just want to relax a bit. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On 03/09/11 03:10, Arun Raghavan wrote: Hello all, Based on the RFC I posted earlier, I've implemented basic passthrough support in some usable shape. It's up on the passthrough branch of each of: PulseAudio: http://git.collabora.co.uk/?p=user/arun/pulseaudio.git;a=shortlog;h=refs/heads/passthrough gst-plugins-base: http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough gst-plugins-good: http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough Hello, I'm wanting to clone the passthrough head but I haven't been able to figure out which git option I need. So far All I've been able to get is master. git ls-remote git://git.collabora.co.uk/git/user/arun/pulseaudio.git dda564f50b55340ff4bfbaa8d6d6fc6427f764f4HEAD dda564f50b55340ff4bfbaa8d6d6fc6427f764f4refs/heads/master b42400816031c17cdf6a63f446510e13d0ab9828 refs/heads/module-echo-cancel aa78853d728172f7fa564b2782f6e84661bfcd15refs/heads/no-ramping 4cd90d9e32ca9a23e3c0f7615974ea0c55ff3e49refs/heads/orc a5b33c7122ee80dc6906fd51f7aa39322322f24brefs/heads/passthrough a4e9e9b631841eac5646b925c198d236c92d8aabrefs/heads/passthrough-bt 3a6dc95735e79f791788cda73a0fc36e46cb43earefs/heads/sq-aec ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On 03/15/11 22:04, Arun Raghavan wrote: On Tue, 2011-03-15 at 18:50 -0600, Kelly Anderson wrote: On 03/09/11 03:10, Arun Raghavan wrote: Hello all, Based on the RFC I posted earlier, I've implemented basic passthrough support in some usable shape. It's up on the passthrough branch of each of: PulseAudio: http://git.collabora.co.uk/?p=user/arun/pulseaudio.git;a=shortlog;h=refs/heads/passthrough gst-plugins-base: http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough gst-plugins-good: http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough Hey Arun, I've built and installed the passthrough branch. Isn't changing sample rates supported yet? So far I can only passthrough sample rates that match the default-sample-rate in daemon.conf. Changeable rates is critical to being able to support for example dts-hd at 192khz, when standard dts will be 48khz. I'm using paplay for basic functionality checks. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On 03/15/11 23:13, Kelly Anderson wrote: On 03/15/11 22:04, Arun Raghavan wrote: On Tue, 2011-03-15 at 18:50 -0600, Kelly Anderson wrote: On 03/09/11 03:10, Arun Raghavan wrote: Hello all, Based on the RFC I posted earlier, I've implemented basic passthrough support in some usable shape. It's up on the passthrough branch of each of: PulseAudio: http://git.collabora.co.uk/?p=user/arun/pulseaudio.git;a=shortlog;h=refs/heads/passthrough gst-plugins-base: http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough gst-plugins-good: http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough Hey Arun, I've built and installed the passthrough branch. Isn't changing sample rates supported yet? So far I can only passthrough sample rates that match the default-sample-rate in daemon.conf. Changeable rates is critical to being able to support for example dts-hd at 192khz, when standard dts will be 48khz. I'm using paplay for basic functionality checks. I forgot to mention that I patched alsa-sink.c with extended rates as per: --- ./src/modules/alsa/alsa-sink.c.orig2011-03-15 22:15:20.701558916 -0600 +++ ./src/modules/alsa/alsa-sink.c2011-03-15 22:37:57.437394161 -0600 @@ -1436,6 +1436,7 @@ static pa_idxset* sink_get_formats(pa_si { pa_idxset *ret = pa_idxset_new(NULL, NULL); pa_format_info *f; +const char *dev_nam = ((struct userdata*)s-userdata)-device_name; pa_assert(s); @@ -1444,12 +1445,12 @@ static pa_idxset* sink_get_formats(pa_si pa_idxset_put(ret, f, NULL); /* FIXME: is there no better way to check for this? */ -if (strncmp(iec958, ((struct userdata*)s-userdata)-device_name, 6) == 0) { +if ( ! strncmp(iec958, dev_nam, 6) || ! strncmp(hdmi, dev_nam, 4) ) { /* FIXME: Eventually, we want the list of supported formats to be set * as properties by the GUI based on what the user says is supported by * the receiver */ /* FIXME: How do we figure out supported rates? :( */ -unsigned int i, rates[] = { 32000, 44100, 48000 }; +unsigned int i, rates[] = { 32000, 44100, 48000, 96000, 192000, 384000 }; /* FIXME: Make only one format_info once we've resolved how to do * lists/ranges in proplists */ ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio xbmc passthrough success
On 03/06/11 14:54, pl bossart wrote: I've got pulseaudio xbmc passthrough working. I've rolled it together with a previously windows c++ library called Ac3Filter. I've been tweeking up Ac3Filter quite a bit. I'm using the Ac3Filter library to Mux spdif. It was a well written library/tools that was relatively easy to get ported to linux. I'm watching Avatar in wonderful DTS surround sound now. All you need is a 3D TV now... Seriously, this is good. Can you send a link to this ported AC3Filter code? I thought it was too Windows/DirectX-oriented to be used. I didn't look too much since it's GPL, and LGPL is preferred in terms of integration with proprietary components. Thanks, -Pierre I've update AudioFilter and the Xbmc AudiFilter patch. It now passes the core dts-5.1 portion of dts-hd audio streams. Supposedly ffmpeg can mux a dts-hd stream that passes through the full dts-hd stream. I want to analyse what ffmpeg is doing to the hd portion of the stream so I can implement it. If anyone knows of the ffmpeg command that will mux a dts-hd stream for spdif let me know. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio xbmc passthrough success
On 03/06/2011 02:54 PM, pl bossart wrote: All you need is a 3D TV now... Seriously, this is good. Can you send a link to this ported AC3Filter code? I thought it was too Windows/DirectX-oriented to be used. I didn't look too much since it's GPL, and LGPL is preferred in terms of integration with proprietary components. Thanks, -Pierre Pierre, OK, I've cleaned the code up and it works really well now (for my purposes). It's really efficient with processing DTS files, I haven't profiled Ac3 yet. I've rolled it into my copy of xbmc and all seems to be working really well. I'll be putting patches for xbmc up as well as soon as I've prep'd them. You could do me a favor if you would complete sink_pulse.{cpp,h}. I've been working on other things and that's really on the back burner for me. Once the SinkPulse is done, we'll be able to play raw DTS/AC3 files pretty much the same way paplay does for other formats. At some point we might even want to roll AudioFilter into paplay. I renamed Ac3Filter to AudioFilter. It really does a bunch more than just Ac3 and I've renamed interfaces, etc. I'm still renaming files and moving the around a bit, but the headers should be pretty stable. http://silka.with-linux.com/audiofilter/ I'll probably put the code in a git repository once I've got the file renaming out of the way. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio xbmc passthrough success
On 03/08/2011 03:32 PM, Kelly Anderson wrote: On 03/06/2011 02:54 PM, pl bossart wrote: All you need is a 3D TV now... Seriously, this is good. Can you send a link to this ported AC3Filter code? I thought it was too Windows/DirectX-oriented to be used. I didn't look too much since it's GPL, and LGPL is preferred in terms of integration with proprietary components. Thanks, -Pierre Pierre, OK, I've cleaned the code up and it works really well now (for my purposes). It's really efficient with processing DTS files, I haven't profiled Ac3 yet. I've rolled it into my copy of xbmc and all seems to be working really well. I'll be putting patches for xbmc up as well as soon as I've prep'd them. You could do me a favor if you would complete sink_pulse.{cpp,h}. I've been working on other things and that's really on the back burner for me. Once the SinkPulse is done, we'll be able to play raw DTS/AC3 files pretty much the same way paplay does for other formats. At some point we might even want to roll AudioFilter into paplay. I renamed Ac3Filter to AudioFilter. It really does a bunch more than just Ac3 and I've renamed interfaces, etc. I'm still renaming files and moving the around a bit, but the headers should be pretty stable. http://silka.with-linux.com/audiofilter/ I'll probably put the code in a git repository once I've got the file renaming out of the way. OK, I've just put up the patches necessary to get passthrough working with Nvidia hdmi on XBMC. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio xbmc passthrough success
On 03/06/2011 02:54 PM, pl bossart wrote: I've got pulseaudio xbmc passthrough working. I've rolled it together with a previously windows c++ library called Ac3Filter. I've been tweeking up Ac3Filter quite a bit. I'm using the Ac3Filter library to Mux spdif. It was a well written library/tools that was relatively easy to get ported to linux. I'm watching Avatar in wonderful DTS surround sound now. All you need is a 3D TV now... Seriously, this is good. Can you send a link to this ported AC3Filter code? I thought it was too Windows/DirectX-oriented to be used. I didn't look too much since it's GPL, and LGPL is preferred in terms of integration with proprietary components. Thanks, -Pierre I'm putting the finishing touches on it, give me a few days. I'm cleaning up the code and putting it in it's own namespace so it'll integrate with large projects without conflict. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Nvidia hdmi passthrough patch
Hey, Here's a patch that I created for git that adds passthrough support for the Nvidia hdmi port. Pretty much just copy/paste from the iec958 sections. --- ./src/modules/alsa/alsa-sink.c.orig2011-02-16 22:58:11.0 -0700 +++ ./src/modules/alsa/alsa-sink.c2011-02-17 02:53:21.452857569 -0700 @@ -1708,7 +1708,8 @@ static int setup_mixer(struct userdata * } /* FIXME: need automatic detection rather than hard-coded path */ -if (!strcmp(u-mixer_path-name, iec958-passthrough-output)) { +if (!strcmp(u-mixer_path-name, iec958-passthrough-output) +|| !strcmp(u-mixer_path-name, hdmi-passthrough-output)) { u-sink-flags |= PA_SINK_PASSTHROUGH; } else { u-sink-flags = ~PA_SINK_PASSTHROUGH; --- ./src/modules/alsa/mixer/profile-sets/default.conf.orig 2011-02-16 22:58:11.0 -0700 +++ ./src/modules/alsa/mixer/profile-sets/default.conf2011-02-17 02:46:25.401973394 -0700 @@ -141,6 +141,25 @@ channel-map = left,right priority = 4 direction = output +[Mapping hdmi-passthrough] +device-strings = hdmi:%f +channel-map = left,right +direction = output +paths-output = hdmi-passthrough-output +priority = 5 + +[Mapping hdmi-ac3-surround-40] +device-strings = a52:%f +channel-map = front-left,front-right,rear-left,rear-right +priority = 2 +direction = output + +[Mapping hdmi-ac3-surround-51] +device-strings = a52:%f +channel-map = front-left,front-right,rear-left,rear-right,front-center,lfe +priority = 3 +direction = output + ; An example for defining multiple-sink profiles #[Profile output:analog-stereo+output:iec958-stereo+input:analog-stereo] #description = Foobar --- ./src/modules/alsa/mixer/paths/hdmi-passthrough-output.conf.orig 2011-02-17 02:40:11.766291419 -0700 +++ ./src/modules/alsa/mixer/paths/hdmi-passthrough-output.conf 2011-02-17 02:39:48.168179164 -0700 @@ -0,0 +1,19 @@ +# This file is part of PulseAudio. +# +# PulseAudio is free software; you can redistribute it and/or modify +# it under the terms of the GNU Lesser General Public License as +# published by the Free Software Foundation; either version 2.1 of the +# License, or (at your option) any later version. +# +# PulseAudio is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. +# +# You should have received a copy of the GNU Lesser General Public License +# along with PulseAudio; if not, write to the Free Software Foundation, +# Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. + + +[Element HDMI] +switch = mute --- ./src/modules/alsa/mixer/paths/hdmi-stereo-output.conf.orig 2011-02-17 02:40:18.921630373 -0700 +++ ./src/modules/alsa/mixer/paths/hdmi-stereo-output.conf2011-02-17 02:39:55.903542803 -0700 @@ -0,0 +1,19 @@ +# This file is part of PulseAudio. +# +# PulseAudio is free software; you can redistribute it and/or modify +# it under the terms of the GNU Lesser General Public License as +# published by the Free Software Foundation; either version 2.1 of the +# License, or (at your option) any later version. +# +# PulseAudio is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. +# +# You should have received a copy of the GNU Lesser General Public License +# along with PulseAudio; if not, write to the Free Software Foundation, +# Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. + + +[Element HDMI] +switch = mute --- ./src/modules/alsa/alsa-mixer.c.orig2011-02-16 22:58:11.0 -0700 +++ ./src/modules/alsa/alsa-mixer.c2011-02-17 02:38:08.117560106 -0700 @@ -1888,7 +1888,9 @@ static int path_verify(pa_alsa_path *p) { analog-output-mono, N_(Analog Mono Output) }, { analog-output-speaker, N_(Analog Speakers) }, { iec958-stereo-output, N_(Digital Output (IEC958)) }, -{ iec958-passthrough-output, N_(Digital Passthrough (IEC958)) } +{ iec958-passthrough-output, N_(Digital Passthrough (IEC958)) }, +{ hdmi-stereo-output, N_(Digital Output (HDMI)) }, +{ hdmi-passthrough-output, N_(Digital Passthrough (HDMI)) } }; pa_alsa_element *e; @@ -2914,7 +2916,10 @@ static int mapping_verify(pa_alsa_mappin { iec958-passthrough, N_(Digital Passthrough (IEC958)) }, { iec958-ac3-surround-40, N_(Digital Surround 4.0 (IEC958/AC3)) }, { iec958-ac3-surround-51, N_(Digital Surround 5.1 (IEC958/AC3)) }, -{ hdmi-stereo,N_(Digital Stereo (HDMI)) } +{ hdmi-stereo,N_(Digital Stereo (HDMI)) }, +{ hdmi-passthrough, N_(Digital Passthrough (HDMI)) }, +{ hdmi-ac3-surround-40, N_(Digital Surround 4.0 (HDMI/AC3)) }, +
[pulseaudio-discuss] Nvidia hdmi passthrough
diff --git a/src/Makefile.am b/src/Makefile.am index 24e2f82..bb501fb 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1131,7 +1131,9 @@ dist_alsapaths_DATA = \ modules/alsa/mixer/paths/analog-output-lfe-on-mono.conf \ modules/alsa/mixer/paths/analog-output-mono.conf \ modules/alsa/mixer/paths/iec958-stereo-output.conf \ - modules/alsa/mixer/paths/iec958-passthrough-output.conf + modules/alsa/mixer/paths/iec958-passthrough-output.conf \ + modules/alsa/mixer/paths/hdmi-stereo-output.conf \ + modules/alsa/mixer/paths/hdmi-passthrough-output.conf endif diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c index fa07674..ad28c41 100644 --- a/src/modules/alsa/alsa-mixer.c +++ b/src/modules/alsa/alsa-mixer.c @@ -1952,7 +1952,9 @@ static int path_verify(pa_alsa_path *p) { { analog-output-mono, N_(Analog Mono Output) }, { analog-output-speaker, N_(Analog Speakers) }, { iec958-stereo-output, N_(Digital Output (IEC958)) }, -{ iec958-passthrough-output, N_(Digital Passthrough (IEC958)) } +{ iec958-passthrough-output, N_(Digital Passthrough (IEC958)) }, +{ hdmi-stereo-output, N_(Digital Output (HDMI)) }, +{ hdmi-passthrough-output, N_(Digital Passthrough (HDMI)) } }; pa_alsa_element *e; @@ -2995,7 +2997,10 @@ static int mapping_verify(pa_alsa_mapping *m, const pa_channel_map *bonus) { { iec958-passthrough, N_(Digital Passthrough (IEC958)) }, { iec958-ac3-surround-40, N_(Digital Surround 4.0 (IEC958/AC3)) }, { iec958-ac3-surround-51, N_(Digital Surround 5.1 (IEC958/AC3)) }, -{ hdmi-stereo,N_(Digital Stereo (HDMI)) } +{ hdmi-stereo,N_(Digital Stereo (HDMI)) }, +{ hdmi-passthrough, N_(Digital Passthrough (HDMI)) }, +{ hdmi-ac3-surround-40, N_(Digital Surround 4.0 (HDMI/AC3)) }, +{ hdmi-ac3-surround-51, N_(Digital Surround 5.1 (HDMI/AC3)) } }; pa_assert(m); @@ -3119,6 +3124,7 @@ static int profile_verify(pa_alsa_profile *p) { { output:analog-mono+input:analog-mono, N_(Analog Mono Duplex) }, { output:analog-stereo+input:analog-stereo, N_(Analog Stereo Duplex) }, { output:iec958-stereo+input:iec958-stereo, N_(Digital Stereo Duplex (IEC958)) }, +{ output:hdmi-stereo+input:hdmi-stereo, N_(Digital Stereo Duplex (HDMI)) }, { off, N_(Off) } }; diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c index 9ed4d4d..e10b99d 100644 --- a/src/modules/alsa/alsa-sink.c +++ b/src/modules/alsa/alsa-sink.c @@ -1708,7 +1708,8 @@ static int setup_mixer(struct userdata *u, pa_bool_t ignore_dB, pa_bool_t sync_v } /* FIXME: need automatic detection rather than hard-coded path */ -if (!strcmp(u-mixer_path-name, iec958-passthrough-output)) { +if (!strcmp(u-mixer_path-name, iec958-passthrough-output) +|| !strcmp(u-mixer_path-name, hdmi-passthrough-output)) { u-sink-flags |= PA_SINK_PASSTHROUGH; } else { u-sink-flags = ~PA_SINK_PASSTHROUGH; diff --git a/src/modules/alsa/mixer/paths/hdmi-passthrough-output.conf b/src/modules/alsa/mixer/paths/hdmi-passthrough-output.conf new file mode 100644 index 000..fe58f68 --- /dev/null +++ b/src/modules/alsa/mixer/paths/hdmi-passthrough-output.conf @@ -0,0 +1,19 @@ +# This file is part of PulseAudio. +# +# PulseAudio is free software; you can redistribute it and/or modify +# it under the terms of the GNU Lesser General Public License as +# published by the Free Software Foundation; either version 2.1 of the +# License, or (at your option) any later version. +# +# PulseAudio is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. +# +# You should have received a copy of the GNU Lesser General Public License +# along with PulseAudio; if not, write to the Free Software Foundation, +# Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. + + +[Element HDMI] +switch = mute diff --git a/src/modules/alsa/mixer/paths/hdmi-stereo-output.conf b/src/modules/alsa/mixer/paths/hdmi-stereo-output.conf new file mode 100644 index 000..fe58f68 --- /dev/null +++ b/src/modules/alsa/mixer/paths/hdmi-stereo-output.conf @@ -0,0 +1,19 @@ +# This file is part of PulseAudio. +# +# PulseAudio is free software; you can redistribute it and/or modify +# it under the terms of the GNU Lesser General Public License as +# published by the Free Software Foundation; either version 2.1 of the +# License, or (at your option) any later version. +# +# PulseAudio is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the
Re: [pulseaudio-discuss] Nvidia hdmi passthrough
I finally got git send-email to work. Had to change my sendmail config. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] pulseaudio passthrough samplerate
Hey, I've been hacking on xbmc - pulseaudio passthrough and I'm getting there a little bit at a time. It seems that at the moment that if the daemon.conf default-sample-rate is set to 44100 then all I can passthrough is 44100 and if it's 48000 all that works are 48000 samples. Is that a limitation in the current pulse implementation? I expected that this would be set from the pa_sample_spec, but that seems to be ignored currently. I'm using paplay --rate ? --raw --passthrough for testing. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] pulseaudio xbmc passthrough success
Yahoo! I've got pulseaudio xbmc passthrough working. I've rolled it together with a previously windows c++ library called Ac3Filter. I've been tweeking up Ac3Filter quite a bit. I'm using the Ac3Filter library to Mux spdif. It was a well written library/tools that was relatively easy to get ported to linux. I'm watching Avatar in wonderful DTS surround sound now. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio xbmc passthrough success
Forgot to mention. I'm getting Hi-def video/audio and only using 8% cpu. That's just awesome. Vdpau is handling the video decode. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pavucontrol. Also Nvidia HDMI
On 02/21/11 17:46, Christopher K. wrote: My second question is about sound over hdmi with an Nvidia GTX460 (NVC4 /GF104 family): aplay -L gives hdmi:CARD=NVidia,DEV=0 - pcm3p/ hdmi:CARD=NVidia,DEV=1 - pcm7p/ hdmi:CARD=NVidia,DEV=2 - pcm8p/ hdmi:CARD=NVidia,DEV=3 - pcm9p/ but only pcm7p actually does anything. So currently I use load-module module-alsa-sink device=hw:1,7 to add a sink, but PA automatically adds pcm3p as GF104 High Definition Audio Controller Digital Stereo (HDMI), so I effectively have two nvidia-hdmi sinks, one of which does absolutely nothing. Is there any way to disable the automatically added sink OR define which device to chose as default? What you want to do is add probe_mask to your snd-hda-intel module options. If you google nvidia hdmi probe_mask you can find an explanation. For example I have in /etc/modprobe.d/snd_hda_intel.conf: options snd-hda-intel probe_mask=0x102 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On 02/18/11 02:41, Arun Raghavan wrote: Hello! On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: Hey folks, I've put up a draft proposed API changes to get passthrough support to the point where things Just Work⢠for at least the common cases, based on previous discussion on-/off-list: http://pulseaudio.org/wiki/PassthroughSupport Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. I've updated this page with the changes discussed so far (and translated them into the actual API changes that we need). Please take a look and let me know if this looks acceptable. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss The alsa driver has creates a /proc entry that lists the coding types available for a particular device. It'd be nice if you would use that for the list of supported coding types (at least for a default). I'm not sure the list would be automatically updated if you unplugged a device and plugged in a new device. The comprehensive list of supported coding types is in alsa-kernel/pci/hda/hda-eld.c. cat /proc/asound/card0/eld#1.0 monitor_present 1 eld_valid 1 monitor_nameTX-SR608 connection_type HDMI eld_version [0x2] CEA-861D or below edid_version[0x3] CEA-861-B, C or D manufacture_id 0xcb3d product_id 0xa62 port_id 0x2 support_hdcp0 support_ai 0 audio_sync_delay0 speakers[0x4f] FL/FR LFE FC RL/RR RLC/RRC sad_count 8 sad0_coding_type[0x1] LPCM sad0_channels 2 sad0_rates [0x1ee0] 44100 48000 88200 176400 192000 384000 sad0_bits [0xe] 16 20 24 sad1_coding_type[0x1] LPCM sad1_channels 8 sad1_rates [0x1ee0] 44100 48000 88200 176400 192000 384000 sad1_bits [0xe] 16 20 24 sad2_coding_type[0x2] AC-3 sad2_channels 8 sad2_rates [0xe0] 44100 48000 88200 sad2_max_bitrate64 sad3_coding_type[0x7] DTS sad3_channels 8 sad3_rates [0xc0] 48000 88200 sad3_max_bitrate1536000 sad4_coding_type[0x9] DSD (One Bit Audio) sad4_channels 6 sad4_rates [0x40] 48000 sad5_coding_type[0xa] E-AC-3/DD+ (Dolby Digital Plus) sad5_channels 8 sad5_rates [0xc0] 48000 88200 sad6_coding_type[0xb] DTS-HD sad6_channels 8 sad6_rates [0x1ec0] 48000 88200 176400 192000 384000 sad7_coding_type[0xc] MLP (Dolby TrueHD) sad7_channels 8 sad7_rates [0x1480] 88200 192000 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On 02/18/11 06:26, Arun Raghavan wrote: On Fri, 2011-02-18 at 03:42 -0700, Kelly Anderson wrote: [...] The alsa driver has creates a /proc entry that lists the coding types available for a particular device. It'd be nice if you would use that for the list of supported coding types (at least for a default). I'm not sure the list would be automatically updated if you unplugged a device and plugged in a new device. The comprehensive list of supported coding types is in alsa-kernel/pci/hda/hda-eld.c. I don't know how it works for HDMI, but if it does update that list based on the receiver, that would be ideal for us, since we should be able to probe that while routing. Well I know for a fact with hdmi it updates the list when the kernel boots. I'm not sure it gets updated if you switch devices after the kernel is up. I'd say in over 90% of the cases it would be correct. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] HDMI passthrough request for help
Hey, With all of the discussions going on about passthrough I thought someone on the list might be able to give me some insight into getting passthrough working properly with xbmc. First of all I patched pulseaudio git with some updates to treat hdmi-passthrough as it does iec958-passthrough. That seems to work. I can use paplay to pass a dts-wav file through to the receiver and the receiver triggers into dts mode and plays it. A native dts file stripped from and mkv movie file on the other hand doesn't play. I made some minor changes to the Xbmc pulseaudio driver so that it does not ignore passthrough requests. Xbmc's pulseaudio driver assumes (without patching) that passthrough is not available for pulseaudio. Now I can select the pulseaudio passthrough device. Xbmc has code in it to manipulate dts streams. The problem is that I can start a movie, Xbmc will select the dts track and play, but the receiver doesn't go into dts mode, but instead just buzzes the speakers. Any ideas? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] HDMI passthrough request for help
On 02/18/11 07:41, pl bossart wrote: First of all I patched pulseaudio git with some updates to treat hdmi-passthrough as it does iec958-passthrough. That seems to work. I can use paplay to pass a dts-wav file through to the receiver and the receiver triggers into dts mode and plays it. A native dts file stripped from and mkv movie file on the other hand doesn't play. I made some minor changes to the Xbmc pulseaudio driver so that it does not ignore passthrough requests. Xbmc's pulseaudio driver assumes (without patching) that passthrough is not available for pulseaudio. Now I can select the pulseaudio passthrough device. Xbmc has code in it to manipulate dts streams. The problem is that I can start a movie, Xbmc will select the dts track and play, but the receiver doesn't go into dts mode, but instead just buzzes the speakers. Did you actually add the PASSTHROUGH flag when you create the pa_stream? When the receiver doesn't lock it's typically when the data was modified by the volume control. Another possibility is mismatch between frequencies. Make sure the sink and the stream sampling frequencies match. Yeah, I added the passthrough flag. The code dealing with volume control has a conditonal around it to ignore requests when using passthrough. I'll look a bit more a sample frequencies. I did change the default pulse frequency to 48000 in daemon.conf, not sure if that was necessary or not. Note that we are completely reworking this part, you may want to wait 1-2 months before the feature becomes more stable. -Pierre Yeah, I know. But I need it now! hehe, I've got quite a few blue-rays that have been put into mkv's and I just bought a very nice surround sound system. Actually I though working on it now would be beneficial both for pulse and xbmc. Xbmc should be able to rock out as soon as pulse is official. I might uncover something useful to pulse while hacking xbmc. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio-0.9.21, alsa-1.0.23, kde-4.4.5, consolekit, dbus
On 09/12/10 19:04, sibu xolo wrote: pcm.pulse { type pulse } ctl.pulse { type pulse } pcm.!default { type pulse } ctl.!default { type pulse } Try the following, it should allow alsamixer to control the default device pcm.pulse { type pulse } ctl.pulse { type pulse } #pcm.!default { #type pulse #} #ctl.!default { #type pulse #} ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio 0.9.21 deadlocking when accessed through OpenAl 1.10.622 (AlienArena)
On 01/05/2010 12:38 PM, Lennart Poettering wrote: On Wed, 23.12.09 13:42, Kelly Anderson (ke...@silka.with-linux.com) wrote: Here's an strace (with prints sprinkled in the OpenAl pulse code) which demonstrates the deadlock. A patch to undo the commit is at the end. Does http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=978d33b609969c3b9bbbd759e0f11aaf856c80cf Fix the problem? volatile does not fix the problem. It still deadlocks unless I revert the original commit. I am quite sure that http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=c5fdbeab85dfe69ebaec92969ec2ce77b105f1df fixes the problem. Could you please verify that? Thanks, Lennart It does not fix the deadlock. I still need to revert the patch that initiated the problem. Here is a copy of the function in OpenAl 1.10.622 with a comment on when and where the deadlock occurs. static ALCboolean pulse_open(ALCdevice *device, const ALCchar *device_name) //{{{ { pulse_data *data = ppa_xmalloc0(sizeof(pulse_data)); pa_context_state_t state; AL_PRINT(pulse_open()\n); if(ppa_get_binary_name(data-path_name, sizeof(data-path_name))) data-context_name = ppa_path_get_filename(data-path_name); else data-context_name = OpenAL Soft; AL_PRINT(starting pa_threaded_mainloop_new()\n); if(!(data-loop = ppa_threaded_mainloop_new())) { AL_PRINT(pa_threaded_mainloop_new() failed!\n); goto out; } AL_PRINT(starting pa_threaded_mainloop_start()\n); if(ppa_threaded_mainloop_start(data-loop) 0) { AL_PRINT(pa_threaded_mainloop_start() failed\n); goto out; } AL_PRINT(starting pa_threaded_mainloop_lock()\n); ppa_threaded_mainloop_lock(data-loop); device-ExtraData = data; AL_PRINT(starting pa_context_new()\n); data-context = ppa_context_new(ppa_threaded_mainloop_get_api(data-loop), data-context_name); if(!data-context) { AL_PRINT(pa_context_new() failed: %s\n, ppa_strerror(ppa_context_errno(data-context))); ppa_threaded_mainloop_unlock(data-loop); goto out; } AL_PRINT(starting pa_context_set_state_callback()\n); ppa_context_set_state_callback(data-context, context_state_callback, device); AL_PRINT(starting pa_context_connect()\n); if(ppa_context_connect(data-context, NULL, PA_CONTEXT_NOAUTOSPAWN, NULL) 0) { AL_PRINT(Context did not connect: %s\n, ppa_strerror(ppa_context_errno(data-context))); ppa_context_unref(data-context); data-context = NULL; ppa_threaded_mainloop_unlock(data-loop); goto out; } AL_PRINT(starting pa_context_get_state()\n); for (;;) { state = ppa_context_get_state(data-context); if(!PA_CONTEXT_IS_GOOD(state)) { AL_PRINT(Context did not get ready: %s\n, ppa_strerror(ppa_context_errno(data-context))); ppa_context_unref(data-context); data-context = NULL; ppa_threaded_mainloop_unlock(data-loop); goto out; } if (state == PA_CONTEXT_READY) break; AL_PRINT(starting pa_threaded_mainloop_wait(), state=%s\n , getContextState(state)); ppa_threaded_mainloop_wait(data-loop); - It consistently deadlocks here the second time through the loop ** AL_PRINT(starting pa_threaded_mainloop_accept()\n); ppa_threaded_mainloop_accept(data-loop); } AL_PRINT(starting pa_context_set_state_callback()\n); ppa_context_set_state_callback(data-context, context_state_callback2, device); device-szDeviceName = strdup(device_name); AL_PRINT(starting pa_threaded_mainloop_unlock()\n); ppa_threaded_mainloop_unlock(data-loop); return ALC_TRUE; out: if(data-loop) { ppa_threaded_mainloop_stop(data-loop); ppa_threaded_mainloop_free(data-loop); } device-ExtraData = NULL; ppa_xfree(data); return ALC_FALSE; } //}}} ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] PulseAudio 0.9.21 deadlocking when accessed through OpenAl 1.10.622 (AlienArena)
AlienArena was deadlocking trying to go through OpenAl which was set to use PulseAudio. After quite a bit of debugging (entering prints in OpenAl pulse code), I finally found a solution with the help of a SUSE bug report. http://lists.opensuse.org/opensuse-bugs/2009-10/msg10497.html which points at this commit. http://git.0pointer.de/?p=pulseaudio.git;a=commitdiff;h=4f5e2b745ea357e2b5c815ff33a556505a7d1f18 Here's an strace (with prints sprinkled in the OpenAl pulse code) which demonstrates the deadlock. A patch to undo the commit is at the end. write(3, pDeviceName:PulseAudio Software\n..., 32) = 32 write(3, qalcOpenDevice:PulseAudio Softwar..., 35) = 35 mmap(NULL, 864256, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f07b822d000 brk(0x626f000) = 0x626f000 write(2, AL lib: pulseaudio.c:356: pulse_o..., 39AL lib: pulseaudio.c:356: pulse_open() ) = 39 readlink(/proc/self/exe, /usr/share/games/AlienArena/crx..., 99) = 31 write(2, AL lib: pulseaudio.c:362: startin..., 62AL lib: pulseaudio.c:362: starting pa_threaded_mainloop_new() ) = 62 pipe([4, 5])= 0 fcntl(4, F_GETFL) = 0 (flags O_RDONLY) fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 fcntl(5, F_GETFL) = 0x1 (flags O_WRONLY) fcntl(5, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 fcntl(4, F_GETFD) = 0 fcntl(4, F_SETFD, FD_CLOEXEC) = 0 fcntl(5, F_GETFD) = 0 fcntl(5, F_SETFD, FD_CLOEXEC) = 0 write(2, AL lib: pulseaudio.c:369: startin..., 64AL lib: pulseaudio.c:369: starting pa_threaded_mainloop_start() ) = 64 mmap(NULL, 8392704, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f07afb57000 mprotect(0x7f07afb57000, 4096, PROT_NONE) = 0 clone(child_stack=0x7f07b03571f0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f07b03579e0, tls=0x7f07b0357910, child_tidptr=0x7f07b03579e0) = 5393 write(2, AL lib: pulseaudio.c:376: startin..., 63AL lib: pulseaudio.c:376: starting pa_threaded_mainloop_lock() ) = 63 write(2, AL lib: pulseaudio.c:380: startin..., 52AL lib: pulseaudio.c:380: starting pa_context_new() ) = 52 open(/home/kelly/.pulse/client.conf, O_RDONLY) = -1 ENOENT (No such file or directory) open(/etc/pulse/client.conf, O_RDONLY) = 6 fstat(6, {st_mode=S_IFREG|0644, st_size=1184, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f07b833e000 read(6, # This file is part of PulseAudio..., 4096) = 1184 read(6, ..., 4096)= 0 open(/home/kelly/.pulse-cookie, O_RDWR|O_CREAT|O_NOCTTY, 0600) = 7 fcntl(7, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0 read(7, d\321\303\334\277\346B\370\217!7\367v.H\261\273\212\222\330))=k\360q\24g\3...@e..., 256) = 256 fcntl(7, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0 close(7)= 0 close(6)= 0 munmap(0x7f07b833e000, 4096)= 0 socket(PF_FILE, SOCK_STREAM, 0) = 6 connect(6, {sa_family=AF_FILE, path=@/tmp/.X11-unix/X0...}, 20) = 0 getpeername(6, {sa_family=AF_FILE, path=@/tmp/.X11-unix/X0\22...}, [139668041498644]) = 0 uname({sys=Linux, node=bs, ...})= 0 access(/home/kelly/.Xauthority, R_OK) = 0 open(/home/kelly/.Xauthority, O_RDONLY) = 7 fstat(7, {st_mode=S_IFREG|0600, st_size=581, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f07b833e000 read(7, \0\0\0\4\300\250\1\7\0\0010\0\22MIT-MAGIC-COOKIE-1\0\20..., 4096) = 581 read(7, ..., 4096)= 0 close(7)= 0 munmap(0x7f07b833e000, 4096)= 0 getsockname(6, {sa_family=AF_FILE, path=@/tmp/.X11-unix/X0\22...}, [139668041498626]) = 0 fcntl(6, F_GETFL) = 0x2 (flags O_RDWR) fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK)= 0 fcntl(6, F_SETFD, FD_CLOEXEC) = 0 poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}]) writev(6, [{l\0\v\0\0\0\22\0\20\0\0\0..., 12}, {..., 0}, {MIT-MAGIC-COOKIE-1..., 18}, {\0\0..., 2}, {lfn\236\303N\331\370\32,\271y\213b;..., 16}, {..., 0}], 6) = 48 read(6, \1\0\v\0\0\0c\0..., 8)= 8 read(6, \230P\243\0\0\0\340\3\377\377\37\0\0\1\0\0\24\0\377\377\1\7\0\0 \10\377\0\0\0\0T..., 396) = 396 poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}]) writev(6, [{b\0\5\0\f\0\0\0BIG-REQUESTS..., 20}], 1) = 20 poll([{fd=6, events=POLLIN}], 1, -1)= 1 ([{fd=6, revents=POLLIN}]) read(6, \1\0\1\0\0\0\0\0\1\216\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 32 poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}]) writev(6, [{\216\0\1\0..., 4}], 1)= 4 poll([{fd=6, events=POLLIN}], 1, -1)= 1 ([{fd=6, revents=POLLIN}]) read(6,
Re: [pulseaudio-discuss] PulseAudio 0.9.21 deadlocking when accessed through OpenAl 1.10.622 (AlienArena)
On 12/23/2009 01:56 AM, Arun Raghavan wrote: On Wed, 2009-12-23 at 01:21 -0700, Kelly Anderson wrote: AlienArena was deadlocking trying to go through OpenAl which was set to use PulseAudio. After quite a bit of debugging (entering prints in OpenAl pulse code), I finally found a solution with the help of a SUSE bug report. http://lists.opensuse.org/opensuse-bugs/2009-10/msg10497.html which points at this commit. http://git.0pointer.de/?p=pulseaudio.git;a=commitdiff;h=4f5e2b745ea357e2b5c815ff33a556505a7d1f18 Are you using openal-soft? If yes, did you try the fix that was mentioned on the bug you referred to? It could be this one (but the dates do not match): http://repo.or.cz/w/openal-soft.git/commit/0e1e8503e0f6fb73d06ba0dff6e5b2771b1df856 If it is that commit, they've restructured their code in context_state_callback and stream_state_callback. That patch will not apply to OpenAl 1.10.622. I'm not too excited about using repository code (although I use it when necessary). IMHO, the pulseaudio commit looks like a suspicious/dangerous optimization. -- Arun ___ 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] PulseAudio 0.9.21 deadlocking when accessed through OpenAl 1.10.622 (AlienArena)
On 12/23/2009 03:04 AM, Colin Guthrie wrote: 'Twas brillig, and Kelly Anderson at 23/12/09 08:21 did gyre and gimble: AlienArena was deadlocking trying to go through OpenAl which was set to use PulseAudio. After quite a bit of debugging (entering prints in OpenAl pulse code), I finally found a solution with the help of a SUSE bug report. http://lists.opensuse.org/opensuse-bugs/2009-10/msg10497.html which points at this commit. http://git.0pointer.de/?p=pulseaudio.git;a=commitdiff;h=4f5e2b745ea357e2b5c815ff33a556505a7d1f18 Here's an strace (with prints sprinkled in the OpenAl pulse code) which demonstrates the deadlock. A patch to undo the commit is at the end. Does http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=978d33b609969c3b9bbbd759e0f11aaf856c80cf Fix the problem? volatile does not fix the problem. It still deadlocks unless I revert the original commit. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss