Re: [pulseaudio-discuss] review+pull-request: Passthrough support
> Yes. The C bits are usually ignored by the receiver since a lot of > sources don't configure them well. But it turns out that in this case > setting the non-audio bit is a mandatory setting. I tried to implement this audio/non-audio switch by playing with ALSA controls, however there are a couple of problems: - the non-audio mode can only be set when the device is closed. There are some protections in alsa-lib, meaning we would need to set this mode on resume and go back to audio mode on suspend. - it took me a while to realize that everything I programmed using alsa controls (snd_ctl*) or configured with iecset on a command line was just overwritten with default values when playback starts. the alsa-lib hdmi/iec958 plugin resets all the values that you carefully programmed with snd_ctl* calls, you really have to pass an argument to this device when it is opened. Boils down to adding ",AES0=0x06" to the device name in passthrough mode. >> Is the ALSA device correctly being configured to 192 kHz? > > I will have to recheck for these two cases. I guess it is since I can > see the D+ logo, but let me confirm for these two cases. The frequency is correctly set: more /proc/asound/card0/pcm3p/sub0/hw_params access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 192000 (192000/1) period_size: 8192 buffer_size: 16384 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
>> Somehow we need to find a way to set this AES0 byte when opening the >> iec958 or hdmi device in the passthrough code, and reset it back to >> 0x04 for PCM playback (should be fairly easy to do by looking at the >> code of iecset in alsa-utils). Beats me why this was not needed for >> plain ac3, but setting the audio bit is actually the correct thing to >> do. > > If my reading is correct, this is something we should do for all formats > anyway? Yes. The C bits are usually ignored by the receiver since a lot of sources don't configure them well. But it turns out that in this case setting the non-audio bit is a mandatory setting. > Is the ALSA device correctly being configured to 192 kHz? I will have to recheck for these two cases. I guess it is since I can see the D+ logo, but let me confirm for these two cases. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
> So far I haven't been able to get anything except stereo working with > passthrough. It seems to me that selecting multiple channels in passthrough > mode would be very similar to the necessary AES0 changes, so maybe we can > get that fixed too. > > I've basically hit a wall by only being able to passthrough 192khz stereo. > When the passthrough data rate exceeds the available rate, my code clips > the data packets. Which seems to work OK when the excess is maybe 200 bytes > or so. On some HD DTS I'm clipping more like 2K per packet which results in > some very nasty sounds emanating from the speakers. Looks like a know issue? I remember some comments/patches from Anssi that if you want to passthrough data at a rate of more than 6.144Mbit/s then yes you need to use AES0=0x06 so that the HMDI hardware uses HBR packets. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
I finally managed to figure out why eac3 wouldn't work in passthrough mode. Apparently my HDMI receiver will only lock on eac3 data if the AES0 control is set to 0x06 (non-audio, ie iec61937). ffmpeg -acodec copy -i csi_miami_5.1_256_spx.eac3 -f spdif outfile.pcm aplay -Dhdmi:AES0=0x6 -fs16 -c2 -r192000 outfile.pcm the same file plays well through pulseaudio if I modifed default.conf to [Mapping hdmi-stereo] device-strings = hdmi:%f,AES0=0x06 channel-map = left,right priority = 4 direction = output Somehow we need to find a way to set this AES0 byte when opening the iec958 or hdmi device in the passthrough code, and reset it back to 0x04 for PCM playback (should be fairly easy to do by looking at the code of iecset in alsa-utils). Beats me why this was not needed for plain ac3, but setting the audio bit is actually the correct thing to do. So far all the tests seem ok with the ffmpeg examples, with the exception of two files: - 7_pt_1: works well with ffmpeg, aplay but the sound is way too fast with pulseaudio. Lots of rewind messages seen in PulseAudio. - serenity_english_5.1_1536.eac3 file: no sound out, and again lots of rewind messages (the receiver still shows the D+ logo though). The same file converted with ffmpeg and played with aplay seems fine. looks like a buffering issue more than a payloader problem really. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] RFC: Filter module loader
> Here is my first draft of a filter module to automatically load > equalizer and/or echo-cancel modules if automagically and in a manual > but convenient way. Thanks for these patches, this is interesting, Arun and I were talking last week about better support for effects, after we realized how apps such as banshee/rhythmbox handle effects and volume ramps with awful hard-coded gstreamer pipelines. All this PCM processing should move to PulseAudio really. Your approach makes sense with the existing solution based on virtual sinks/sources, but with the current implementation, the effects are really global, post-mix. If you want to add an effect on a specific stream, you need to create a new sink and move the sink-input. That really doesn't scale. Ideally we would want to use a linked list of effects, so that the effects can be added/enabled/disabled/removed quickly and their order modified, and we should be able to handle - local/per-stream effects. - global/post-mix effects - aux effects (such as reverb) We would also need a standard way for apps to set/get the parameters needed by effects. This isn't new, this is what Android/AudioFlinger/OpenSL ES implement. In most cases, users really care about global effects only, but you may want to have a specific filter on a stream (ReplayGain or some volume ramp for example). I also don't think using a 10s timer is really great to check if the effect is actually needed. If you had a linked list you wouldn't need to do this type of things. let me know if I am making any sense, it's been a long week... -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
> Jack detect does not use the ALSA kernel subsystem but does instead > use the input subsystem for jack status. It makes sense to create a > new module so we can then use jack detect for non ALSA sound devices. I'm a bit lost here. What are 'non ALSA sound devices'? And to the best of my knowledge these events are only generated by ALSA drivers... Am I missing something here? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
>> I've not looked specifically at the code, but I'd have expected that >> jack detection would somehow be built into module-alsa-card or >> module-alsa-source/sink rather than shipped as a separate module (tho' >> I'm maybe not appreciating some intricacy here)... I'll try and review >> the code soon (although others may have beaten me to it anyway :D) >> > > Well the UCM code corresponding on what to do when jack is plug or > unplug its part of module-alsa-card but we had to add first the logic > in PA to detect the jack insertation/removel that it is basically a > listener of /dev/input/eventX, that is used by the kernel to report > the event. All the logic for jack detection has been added in a new > module. > > I'll wait your feedback/questions related to UCM integration :) I have pretty much the same feedback as Colin. First I cherry-picked the two jack-sensing patch and installed them on my laptop (68293cd29b1dcb6b555edeaa5d63110164e5c794 and 6c4a7de60040d5dc3d3b44461a7f490e3feba26f). Works fine, the events are detected. This is something that we've needed for some time. Thanks! But then I looked a the flows and was confused by the design. - It's not clear why you would create a new thread using pthreads rather than pa_create_thread()? Is there any technical reason why the abstraction isn't enough - this thread blocks on a read, and whenever a jack insertion/removal is detected it fires a Hook which is then used by module-alsa-card to actually switch profiles in two callbacks. Why not implement this thread as part of module-alsa-card then? What if the benefits of using the hook as a communication means between two modules? I can see though the benefit of using a hook for, say, an effect that is enabled only for a headphone. That is more the intended use of a hook I believe. While I am at it, I am not even sure you need a thread for this with all the event loops, iochannels and stuff that PulseAudio/glib provide. We may also want to switch the card profiles even if the card isn't supported by UCM. Last, I looked at the two callbacks you implemented, looks to me that the insert and remove parts do the same thing? Shouldn't you memorize the current device, switch to the headphone upon jack insertion and restore the previous device on removal? Maybe this needs to be linked with how PulseAudio memorizes the devices or Colin's device-manager? -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] intermittent audio
> I'm not sure if this is the right venue, but I'm not sure where else to ask. > If there's a more appropriate place, please let me know. > > I recently upgraded my MythTV server from Fedora 11 to Fedora 14. Now the > only way to get sound to work is to follow these steps: > > Start the audio source so that there's an audio stream > Open the Pulseaudio Volume Control panel > Click the "Configuration" tab, > Change "Internal Audio" to any profile other than the current one > Change "Internal Audio" back to the original profile ( Digital Stereo Duplex > (IEC958) ) > > At this point, the audio works. But if I change from watching one show in > MythTV to another, I have to go through the whole process again. It's like > as soon as pulseaudio loses a signal, it has to be reset. The issue is odd > enough that I don't even know what keywords to search for to see if this is a > common problem - has anyone heard of this? Does anyone have any suggestions > for how to fix or troubleshoot it? > rm -rf ~/.pulse* pulseaudio -vvv 2> log.txt pastebin log.txt and send us the link ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
Margarita: I wasn't really able to try out your patches and figure out what they entail since your version of pulseaudio is _very_ old. I tried to merge them one by one, you'll find the result attached. I compiles with git master and if UCM is disabled in module-alsa-card things seem to work fine, so no side effects. Can you let me know if I missed something, and better yet, can you move to something more recent? Thanks, -Pierre magi.patch Description: Binary data ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] modules/bluetooth/sbc/sbc_primitives.h:41:22: error: expected ':', ',', '; ', '}' or '__attribute__' before 'X'
Well you are lucky to even compile, I get a bad dependency with git master. CCLD libbluetooth-ipc.la make[3]: *** No rule to make target `modules/bluetooth/sbc.c', needed by `libbluetooth_sbc_la-sbc.lo'. Stop. [ume@plb pulseaudio]$ git bisect bad e4eb4670108ad2b4a0d9c3044e12ed0d933f834e is the first bad commit commit e4eb4670108ad2b4a0d9c3044e12ed0d933f834e Author: Luiz Augusto von Dentz Date: Mon Mar 14 14:46:10 2011 -0300 build: move sbc related files to its own directory This should make it easier to apply patches from BlueZ which also uses sbc subdir for this files. Went back to before the sbc updates. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] loopback: Always use the trivial resampler.
> It might be that you have misunderstood the reason for the patch. Now > that I read the patch description again, it indeed isn't entirely clear: > the problem that I'm having is that the periodic (every 10 seconds) > reinitialization of the resampler takes too much CPU time. The > resampling itself is fine - I don't think it's even possible to move > that out of the IO thread, or if it's possible, it probably wouldn't > bring any benefits. ok, makes more sense now. Could it be that this reinitialization isn't optimized for your platform (Assuming it's Armv7-Neon?) -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
> 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. -Pierre 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. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] loopback: Always use the trivial resampler.
> The sink may be running in a low-latency mode even if the loopback > stream doesn't have any latency requirements - there may be other > streams active at the same time with stricter timing requirements. > > FWIW, the practical case here was a very simple test of looping null > sink's monitor to a hw sink with default settings on Harmattan. It may > be that our setup is more suspectible to this kind of problems than > "normal" systems, but I still think that non-realtime-safe stuff should > be kept out of the IO threads, regardless of the setup, especially if > such stuff can very well be done outside the IO thread. if you are still using 10ms periods on the hw sinks, then yes it's an artifical use case in a constrained environment that doesn't use timer-based scheduling... I don't disagree that doing SRC in an io thread is not that kosher, but keep in mind that we also do mixing and volume control in the IO thread. There is some amount of DSP in this thread which will impact response time to hw events. Maybe your idea of linking latency with SRC quality makes sense. I feel however that the speex SRC is not up to snuff and results in high CPU usage. If we fixed the SRC to use a 'reasonable' MHz figure this problem would go away. Loopback is used in Medfield for FM playback only. I haven't heard of any issues. The only bugs on loopback I've seen are on erratic src adjustments on BT A2DP and RTP RX, but I haven't tried since Maarten contributed patches. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] loopback: Always use the trivial resampler.
On Thu, Mar 24, 2011 at 8:16 AM, Tanu Kaskinen wrote: > Adjusting the sample rate is done in the IO thread, which can cause > interruptions in the audio if the adjustment requires heavy computation. The > trivial resampler is guaranteed to be light on the cpu. > > It would be better to adjust the sample rate in some other thread (FWIW, > module-combine uses the main thread), but this quick hack fixes the immediate > problem of spending too much time in the IO thread. I don't think it's the right or only way to solve the problem. If you are using the loopback and SRC is required, the assumption is that you don't care too much about latency. If the audio events are spaced enough, there should be plenty of time to run the resampling. we should instead adjust the sink/source latencies to reduce the number of events and not compromize on quality. This trivial resampler should only be used if for some reason you want both real-time behavior and low-latency while using an SRC. I fail to see in what cases you would care? In what practical cases did you encounter underflows? -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
> I pushed your change along with a fix for the assert you saw to my tree > as well. I tested the latest batch of patches with AC3/SPDIF this time. Works well in general, however I found some interesting points: - in Rhythmbox, the passthrough mode is only enabled if the first file of playlist is compressed. If you start with PCM/WAV, it always uses the PCM mode. - in Totem, the passthrough mode works when the visual effects are disabled. I see a nice DD on my receiver...However the playback stops if you play with the volume slider. I get a pop-up error window saying 'an error occurred: pa_stream_set_sink_input_volume(): invalid argument' On a related note, maybe we want to change the approach to volume control. Depending on the sink, there might be ways of using side/in-band channels to send volume control information to the decoder. It's going to be protocol-specific. So maybe we need to provide the client with an information coming from the sink on whether volume control is actually supported or not. -Piere ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
> I would suggest to use the new API to implement audio passthrough for > bluetooth devices, it is very likely the we will be disabling unix > socket IPC in BlueZ. What I would do is, if audio passthrough is > supported then PA register a mp3 endpoint and try to configure both > sbc and mp3 simultaneously (only one active at time) when possible so > we can quickly switch between codecs. Luiz, what is the time frame for removal of this socket IPC? Will it still be supported in Meego 1.2, 1.3, etc.? I don't disagree this is the right thing to do, I am just wondering if we would run into some integration issues that would actually delay the availability of MP3 passthrough by moving too quickly. Or maybe we can have the two approaches supported and remove this initial version at a later time? Thanks, -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
>> Other things I noticed: the volume is much higher in passthrough mode, >> maybe we need to find a way to set the volume on the headset to match >> the volume used for PCM. Also I heard some high-frequency modulations, >> typically coding noise, maybe there's still something fishy during the >> mp3 decode part. > > I get this sort of thing on, as far as I can tell, one channel as well. > I figured the decoder on the CSR chip wasn't that great. Looks to me that the quality is slightly worse than with the initial patches, but it's of course a very subjective assessment since I need to reinstall pulse/gstreamer to check the differences instead of doing an A/B test. Can you check and make sure the payloader doesn't skip/change any bytes? If you dump what is actually sent to the headset and compare to the initial file, you shouldn't have any deltas. Thanks -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
> I forced support for pulse1.0 it by hand in config.h and found the > same problem with the headset. Trying to figure out the differences > with my initial patches. there must be a step missing. ok, found a solution, see diff attached. For some reason the setup_ad2p() did both the SBC and MPEG configuration. Adding a test for the mode solves the issue, probably there was a buffer overflow or something bad. playing with SBC and MPEG works fine now, meaning that the negotiation works well depending on the payload. but when I try to go back to PCM/SBC the second time I get the following assert in pulseaudio (see gst log below) E: module-bluetooth-device.c: Assertion 'u->write_memchunk.length == u->block_size' failed at modules/bluetooth/module-bluetooth-device.c:1519, function a2dp_process_render(). Aborting. I'll let you debug this one, should be easier :-) Other things I noticed: the volume is much higher in passthrough mode, maybe we need to find a way to set the volume on the headset to match the volume used for PCM. Also I heard some high-frequency modulations, typically coding noise, maybe there's still something fishy during the mp3 decode part. -Pierre [gst-plugins-good]$ gst-launch --gst-debug=pulsesink:5 filesrc location=~/AURAL/Audio/theTest-320.mp3 ! flump3dec ! pulsesink device=bluez_sink.00_0B_E4_94_31_9D Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock Got EOS from element "pipeline0". Execution ended after 9540609373 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... [gst-plugins-good]$ gst-launch --gst-debug=pulsesink:5 filesrc location=~/AURAL/Audio/theTest-320.mp3 ! mp3parse ! pulsesink device=bluez_sink.00_0B_E4_94_31_9D Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock Got EOS from element "pipeline0". Execution ended after 9551288915 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... [gst-plugins-good]$ gst-launch --gst-debug=pulsesink:5 filesrc location=~/AURAL/Audio/theTest-320.mp3 ! flump3dec ! pulsesink device=bluez_sink.00_0B_E4_94_31_9D Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPipeline:pipeline0/GstPulseSink:pulsesink0: Failed to connect stream: Connection terminated Additional debug info: pulsesink.c(1005): gst_pulseringbuffer_acquire (): /GstPipeline:pipeline0/GstPulseSink:pulsesink0 ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... diff-arun.patch Description: Binary data ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
> There was one bit from pulsesink in gst-plugins-good that I'd missed > pushing till a couple of hours ago which actually enables MP3 support on > the pulsesink side. I'm guessing that is missing in your tree? Nah, I traced the problem to the configure step in gst-plugins-good. Somehow my version of pulseaudio isn't detected. Not sure what info the script relies on, it thinks I am based on 0.9.19 when I am using git master. I forced support for pulse1.0 it by hand in config.h and found the same problem with the headset. Trying to figure out the differences with my initial patches. there must be a step missing. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
> I've pushed updates to passthrough-bt branches on my trees for > pulseaudio (some core changes, rebased to current master), > gst-plugins-base (MPEG audio payloader), and gst-plugins-good (pulsesink > MPEG support). With all this, you should be able to test on your BT > headset. I've got all these hanges, but still no luck. [ume@plb GST]$ gst-launch filesrc location=~/AURAL/Audio/theTest-320.mp3 ! pulsesink device=bluez_sink.00_0B_E4_94_31_9D Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPipeline:pipeline0/GstPulseSink:pulsesink0: The stream is in the wrong format. Additional debug info: gstbaseaudiosink.c(914): gst_base_audio_sink_preroll (): /GstPipeline:pipeline0/GstPulseSink:pulsesink0: sink not negotiated. ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... [ume@plb GST]$ gst-launch filesrc location=~/AURAL/Audio/theTest-320.mp3 ! mp3parse ! pulsesink device=bluez_sink.00_0B_E4_94_31_9D 0:00:00.022098216 30380 0x8add070 ERROR GST_PIPELINE ./grammar.y:614:gst_parse_perform_link: could not link mpegaudioparse0 to pulsesink0 WARNING: erroneous pipeline: could not link mpegaudioparse0 to pulsesink0 what I am missing in the setup ? PCM playback seems to work fine. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
Looked at the BT modifications, doesn't look too bad. I would try first with MP3 support only, so that you don't have reconfiguration issues. If you support MP3 only from the beginning, it should be easier to make progress. If you can work on integrating the payloader in gstaudioiec61937 I will be able to help you then. Thanks, -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Still some SIMD issues
> When testing with a52, reducing the volume of the Front Centre channel > to 50% vs. 100% for the others, causes a high pitched artefact to be > introduced. > > exporting PULSE_NO_SIMD=1 prevents the problem (although I do still seem > to get some artefacts when mixing - but this could be due to lack of > rewind on a52 or somehow related to that). > > Just mentioning here by way of recording the issue. I've had the same issue for ages when playing back multichannel files, be that on a HDMI or local stereo out. When all the channels have the same volume everything's fine. When a single channel has a different setting from the others, there' s this high-frequency pitch. It's been a year at least but I've never had the time to look into this. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
Hi Arun,
I looked at the passthrough branch. Looks pretty good. I wrote down some notes:
gstaudioiec61937:
- need to check that frame is valid and synchronized on AC3 header
before pushing iec payload
- no code for mp3 and dts?
pulsesink:
- do we really need two steps for payload and commit? Make
things complicated and creates memory copies
- commit needs to prevent toy resampler (maybe this means the sink
cannot work iwth a live source since no adjustment is possible.
- spec.latency_time = GST_BASE_AUDIO_SINK (psink)->latency_time;
if (!gst_ring_buffer_parse_caps (&spec, caps))
goto out;
Does this work? spec is not initialized?
- change of routing?
- formats
/* 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 };
For HDMI and SPDIF, 32,44.1 and 48 are mandatory. I think you can
query the alsa layer
to give a range of supported frequencies since this is known in
the driver (either hard-coded or obtained with EDID/eld). I remember
seeing some ALSA patches on this for the NVIDIA cards.
sink.c
- how do we notify client that volume is disabled?
I wasn't too clear on the BT support. You mentioned that it was a
different branch and that it stilll nneds my patches to gst-ugly. We'd
need to have the payloader code in gsraudioiec61937 instead? I am also
not sure how we handle the transition from A2DP w/ SBC to A2DP w/ MP3.
In the current code for iec958, there's no need to reconfigure the
link.
Last, I had 3 conflicts with git master that I had to solve by hand.
Thanks
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
>> What's here? All the basic plumbing for clients to signal a compresed >> format, have PA pick the "best" supported one, actually play that >> format, and have pactl list show these. The ALSA sink takes AC3 at the >> moment, and I should be pushing DTS support today/tomorrow after some >> more testing. I'll give it a try later this week. Thanks! -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] Reconfigure sample rates on resume
> At sink-input trigger a reconfiguration if possible/supported. Sinks > expose a reconfigure_rate method (I'm sure we can find a better name) if > they can do a quick switch. So far it's similar to the update_rate() method I added on the sink, > In the ALSA sink, this function would check if there are no sink-inputs > attached and the rate is supported, and then send a message to the I/O > thread to do the actual reconfiguration. We would cache the rate if > suspended and apply on unsuspend, or do a suspend-reconfigure-unsuspend > if it's running. It's interesting. The only problems I see is a potential duplication of code, since you force the suspend in the sink, and it's already part of module-suspend-on-idle. Meaning you will need to implement this message in the BT sink as well. I wonder if there would be potential races if the suspend-on-idle timeout happens right after you enable the new stream. > With this, we can replace default-sample-rate with a minimum-sample-rate > (anything below this gets upsampled), and use the sink-input sample rate > if supported (or an integer multiple as your code does). The advantage > of course is that we're no longer restricted to two sample rates. I don't really see a benefit of having more than 2 sample rates. The only exception is passthrough, where you want to forward the sink-input frequency as is. And reading again I think it's the same behavior I implemented? > I did a quick walk over the code and this seems feasible. I'm doing > something similar (but far simpler) for passthrough mode in alsa-sink - > when a passthrough input is added, I do the > suspend-update_rate-unsuspend if required and it seems to work fine. > > Does this make sense or am I missing something basic here? Couldn't you add the same behavior with my patches? If the sink-input is passthrough then the desired rate is the sink-input rate. Overall I am still not clear on what your alternative implementation brings? But I am badly jet-lagged, I may have missed something as well. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio xbmc passthrough success
> 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio passthrough samplerate
> 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. Yes it's a know limitation I mentioned in my previous emails. Somehow we will need to reconfigure the passthrough sink frequency. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
> the idea was to have at least one card working, so yes this is pretty > much the same approach than the code in module-alsa-card. Do you have > any idea on how to manage virtual cards? I'm not clear on they way > that ALSA manages virtual cards. I am not clear either. I asked a question on this on alsa-devel, but the answer from Jaroslav was quite short. I am still unsure how you actually know when a virtual card is present. I hoped someone could explain the concept in practical terms, looks like we are all lost here. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Virtual Sink Template (was Re: [PATCH 6/6] virtual-sink: Fix a crash when moving the sink to a new master right after setup.)
> Well, it is a template, but it's also fully functional. The > functionality is just very limited :) > >> If it's not wrong, should the changes there to modargs etc. be migrated >> to the modules which have been spawned from virtual sink? > > I believe there aren't actually any modules yet spawned from the virtual > sink. We have internal modules based on the virtual sink. I guess the echo canceler was also derived from the same concept. And it was based on the LADSPA sink in the first place. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
> Modifiers can be used in the following situations:- > > 1) Music is being played. Pulseaudio has configured the Music use case > verb via UCM. The system wants to play a tone, this could be a beep or > even a ring tone for an incoming call. Pulseaudio would then check for a > UCM "play tone" modifier for the current verb and then enable the > modifier if it exists. This "play tone" modifier would setup the > hardware to play both Music (i.e the verb) and additionally tones (the > modifier). The modifier may use a different ALSA pcm and hardware volume > controls to that of the main verb. > > If no "play tone" modifier exists then Pulsewould mix the tone into the > music being played in software as it does atm. > > 2) Phone call is in progress. Pulseaudio has enabled the phone call UCM > verb. The user wants to play music on the phone call. The modifier would > be "Music" so Pulseaudio will check that a modifier exist for this when > the phone call verb is active and enable this modifier. > > If no music modifier is available in the phone call verb configuration > then pulseaudio would mix the music and voice in software. Make sense. But I am not sure the profiles as defined today in PulseAudio can work with modifiers. What we discussed yesterday is that when a profile is selected then you would set the UCM verb and know about all possible sinks. We would need additional logic to have profile modifiers, or we would need extra profiles to represent all possible combinations (speech, speech+tone, speech+music, etc). -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
> The initial version of the UCM module is available at the following link: > http://git.slimlogic.co.uk/cgi-bin/cgit.cgi/pulseaudio.git/log/?h=9.20-ucm_module > > I'm still working in the module, It is work in progress to verify the > current verb when the stream is closed, also it is needed to add more > code to work with the profiles and the use cases. Sink, source and > device data could be taken from the proplist of the verb, and this is > pending too. Hi Margarita, I looked at your patches and have the following comments: - any reason why your version of PulseAudio is 1.3 years old. The previous patches on your branch are from 2009-11-18, quite a while ago. It'll make upstreaming difficult. - you now have a separate module-alsa-ucm module, but it's called with a device name as a parameter. So if I have one USB headphone and one USB mic, this module will be called twice. It's not clear to me then how the virtual device would be handled, and how this is different from inserting all the code in module-alsa-card as you did it in your previous version? - can you explain why you set the verb using the hook PA_CORE_HOOK_SINK_INPUT_NEW, with priority PA_HOOK_EARLY+15. There are other audio-policy related modules that may use different hooks, such as PA_CORE_HOOK_SINK_INPUT_PUT. I would think you want to set the verb at the UCM level after all this logic has made decisions, at the last possible moment before data start flowing. - how do we make use of modifiers? - is there a better way to detect that UCM is supported, instead of having a #define in module-alsa-card.c? I realize I have more questions than suggestions, this is a good start anyway... Thanks, -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, Feb 22, 2011 at 2:52 PM, Tanu Kaskinen wrote: > On Wed, 2011-02-23 at 01:00 +0530, Arun Raghavan wrote: >> On Tue, 2011-02-22 at 13:27 -0600, pl bossart wrote: >> > ok. Looks good. >> > One last comment on proplists. If we don't define a set of mandatory >> > elements, then it's going to be really hard to use this >> > pa_stream_new_extended() routine. How will the client figure out what >> > exactly it needs to send for each format? >> >> I was thinking that his would basically develop as convention, though >> the few basic properties (rate, channels) could be documented along with >> the pa_encoding_t structure. We can document additional properties (for >> example bitrate, if some sink ever needs it) as being optional but >> recommended if available. > > The set of parameters can potentially grow forever - we don't know what > parameters may become relevant in the future. So, I think we should > start by documenting the parameters that we know are important today, > and define the approach for adding new parameters in the future. I suggest we first work with known mandatory parameters such as sampling freq and nb of channels. The connection fails if these parameters are not set. That's enough to make passthrough work for now. Future extensions can be worked out later. let's not fall into academic debates. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
>> One last comment on proplists. If we don't define a set of mandatory >> elements, then it's going to be really hard to use this >> pa_stream_new_extended() routine. How will the client figure out what >> exactly it needs to send for each format? > > I was thinking that his would basically develop as convention, though > the few basic properties (rate, channels) could be documented along with > the pa_encoding_t structure. We can document additional properties (for > example bitrate, if some sink ever needs it) as being optional but > recommended if available. To make things clearer I would add the sampling rate as a mandatory property in the RFC. the number of channels may be unknown before you actually decode, and for an IEC format the number of channels seen by PA is 2... -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
>> Still, I am not clear about the negociation. the client would need to >> use pa_stream_new_extended with multiple formats, and then get the >> actual format with get_format_info. If my understanding is correct, >> then maybe you would need a list of formats instead of just one? > > Oh, indeed! That was the intention, but I guess I missed putting that in > the wiki. Fixed now. ok. Looks good. One last comment on proplists. If we don't define a set of mandatory elements, then it's going to be really hard to use this pa_stream_new_extended() routine. How will the client figure out what exactly it needs to send for each format? -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
> I assume that the every sink that supports PCM will have one format with > PA_ENCODING_PCM in its list of supported formats. With the extended API, > I'd like to treat PCM and compressed formats as being equal as much as > possible. ok, now I get it. I didn't see the PA_ENCODING_PCM on the first line... Still, I am not clear about the negociation. the client would need to use pa_stream_new_extended with multiple formats, and then get the actual format with get_format_info. If my understanding is correct, then maybe you would need a list of formats instead of just one? >> - in case the routing changes, for example if you plug HDMI or BT, how >> do we change the connection? > > The plan is to have clients disconnect and recreate the stream. We could > eventually look at a convenience API to do this. Yes, we can do this later. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
Hi Arun, >> > 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. Couple of comments: - There is a miss on the pa_format_info. the sampling frequency is required. The IEC format can be used at various sampling frequencies. Passing just IEC isn't enough to configure the link with the receiver. The number of channels could be 2 by default, but we may need to change this as well for formats like TrueHD or DTS Master. - in case no IEC formats are supported by the sink, what is the returned value? If this is NULL, meaning there is no support, how do we fall back to plain PCM? - in case the routing changes, for example if you plug HDMI or BT, how do we change the connection? Thanks, -Pierre ___ 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
> There are a few things missing for me to have xbmc+pulse working well > with a surround system over HDMI: > - volume control when in passthrough mode > - volume control via the amplifier; I see 2 methods here: > - either via HDMI CEC, but from the latest spec the only > available commands are volume-up and volume-down, no way > to directly set a volume, nor to calibrate it properly > - via a serial cable, it's amp-specific but more capable > - [off topic] more than 2 PCM channels via HDMI radeon drivers Does any of these features work with plain ALSA? I don't think what you describe is a PulseAudio limitation? -Pierre ___ 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
> 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. Note that we are completely reworking this part, you may want to wait 1-2 months before the feature becomes more stable. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
>> - I am not sure I understand how/when the query would be used. Seems >> to me like a notification with the formats exposed by the sink >> currently selected would be more usable. And if a change in routing >> happens (new accessory, audio policy, etc), the client is informed and >> can reconfigure to PCM if need be. > > In this scheme, how would the client first determine what formats are > available? The notification will also be required - we can either > piggyback in sink, sink-input and card change notifications, or > introduce a new one for a change in available formats (I prefer the > latter). The problem is that you don't know on what sink you will play until you have actually created the pa_stream. The audio policy and routing rules may kick in and if you query before you connect you would end-up with a broken configuration. One possibly is to connect as PCM, then get a notification from the sink that it can actually support compressed data and then configure the stream. Another possibility is to connect but ask the sink to provide its capabilities in return. We would then have another call to refine the stream configuration. Maybe we should have a short call on this. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
>> > Fair enough. The only niggling API change would be adding a >> > PA_FORMAT_PCM_ANY (it would be unwieldy to return one pa_format_info for >> > each PCM format). >> >> I think the PA_SAMPLE_* enumeration should be left alone. Let it be a >> legacy thing for clients that aren't interested in anything else than >> PCM. pa_format_info doesn't need the pa_sample_spec member. The encoding >> type can be provided with a new enumeration with PA_ENCODING_PCM, >> PA_ENCODING_MP3 etc. Then the proplist, or whatever is chosen for >> representing the format set, can contain information saying that >> everything is supported. > > I didn't get the last bit about what you'd add to the proplist. The > separate enum would work well for the format_info struct, but would you > also suggest extending the API to use the encoding type while setting > up/connecting streams? I agree with Tanu. Changin the PA_SAMPLE_ enum will open a can of worms since it will create an issue with the byte-to-ms conversion. I tried in the past and it became a nightmare, I had to change code everywhere and had to lie on the results. For the passthrough to work, you want the IEC bistream to look like PCM 16/32 bit stereo so that these conversions are well handled. You would use a tag/flag/proplist to make sure the binary data isn't modified/resampled/etc. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
> Please review/comment. Once we have some consensus, I'll send in patches > to actually get this done. Thanks Arun, this is a good start. Couple of comments: - change raw to PCM, it's less ambiguous. - I am not sure I understand how/when the query would be used. Seems to me like a notification with the formats exposed by the sink currently selected would be more usable. And if a change in routing happens (new accessory, audio policy, etc), the client is informed and can reconfigure to PCM if need be. - I think we need to look at the 'start_move' and 'finish_move' as well. If a reconfiguration to PCM is needed, we may need to wait until the client sends PCM again? - I am not sure the channel map matters for compressed data. The receiver will adjust anyway to the actual number of speakers, e.g. downmix if you use a headset. - you want to add E-AC3 as a basic format. It uses a different IEC syntax - The receiver may support the same format at different sampling frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for BT). We will need to list explicitly which sampling frequencies are supported for each format. - Changing the monitor is tricky, we may want to keep it but either tag the data as IEC as well, or just zero out. - On deprecating the PA_SINK_INPUT_PASSTHROUGH: yes it can be removed as long as you have some means to signal that the data isn't your ordinary PCM. Extending the pa_sample_spec would break the API, I vote for a proplist here. I am sure others will have some remarks as well. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
>> How about reusing gstreamer formats, so that adding a new format to PA >> makes it appear automagically in apps using GST (no need to recompile >> GST) ? > > Tempting as it is ;), we want to keep PA framework-agnostic. Also, in > most cases, you will likely need to update pulsesink on the GStreamer > side anyway to do some sort of payloading (IEC 61937 in the formats > we're talking about now). Actually Gstreamer would need to add a set of IEC61937 formats as well. The current IEC968 format exposed in gstreamer can mean either PCM or compressed but doesn't differentiate between, say, AC3 and DTS. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
Hi Margarita, > I've created some code that can read this data out of UCM in module > alsa-card but I'm now looking for the best way to store this into the > prop list for the sound card. e.g. should I extend intended roles > proplist or add new proplist types for UCM. As I wrote in my comments on alsa-devel, I don't think it's right to read UCM properties in module-alsa-card. For virtual cards, eg. a USB headphone and a USB microphone, you will have 2 cards part used for the same verb. It'd be weird to store UCM values twice. In addition, somehow we have to reconcile the static list of cards/devices in UCM configurations with the way PulseAudio detects hardware. I would think UCM information should be stored in a core proplist by a standalone module that runs on startup (before module-udev-detect), and when a card is detected with udev events you can identify in module-alsa-card which configuration to use. Only then can you set the UCM verb/devices for that specific card based on the role indicated by clients. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Problems running pulseaudio on Slackware based system
> Jan 28 20:32:01 kongoni pulseaudio[2504]: module-alsa-card.c: Failed > to find a working profile. > Jan 28 20:32:01 kongoni pulseaudio[2504]: module.c: Failed to load > module "module-alsa-card" (argument: "device_id="29" > name="platform-thinkpad_acpi" I am getting the same errors on a Thinkpad W500. It doesn't look like it has any impact on the sound. If I "mmod thinkpad_acpi" the audio outputs work just fine -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate
> FWIW, the zero-length wait seems to work fine for me as well (also > HDAudio). A couple of things to consider if we do decide to go ahead > with this are are that: Any ideas on how we can make this timeout sink-specific? Everything I know of (default.pa, module-udev-detect) will set this timeout for all possible sinks. Not clear to me how I can make this configuratble. Properties maybe, but I don't know how to set them with a command or configuration file. > * We probably need to be more intelligent about resetting the alsa-sink > smoother since it tends to swing wildly for a while after resume (right > now it gets reset on every suspend/resume - probably makes more sense to > only reset if some minimum amount of time has passed) Good point. Didn't think about that one. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate
>> I'll do more testing later today. I could see some issues with >> networking or interfaces like S/PDIF or HDMI, where the receiver needs >> to relock. But for local playback we should be fine. You will still > > Not always - anything which doesn't bias the outputs to zero volts (and > even some things that do) is likely to have some pop/click or delay > issues on powerup. Newer hardware will generally do better here but not > everyone uses the latest shiny. Agree. I guess if we keep this configurable, the users can decide if they want to reduce CPU usage/power consumption at the possible expense of added delays and potential click/pops on the transitions. It will really depend on usage, hardware support and preferences. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Dynamic growth of buffer size
> Along with increasing the buffer size, the tsched wakeup watermark will need > to be increased, although my initial prototype code did not do that. I > waited until the watermark increased to the point where there were no more > underruns before using powertop. On my PC, it seems like the process for > decreasing the watermark is very aggressive, maybe to the point of causing > more underruns than needed. > > I plan on doing more testing, but on an ARM based platform, obviously, I am > looking for a buffer growth tuning for ARM that will reduce CPU wakes. For > dynamic growth, I am thinking that with the check_left_to_play (alsa-sink.c) > when woken by a timeout, it would be a good time to try to increase buffer > size and hopefully allowing ARM to go to a lower power state on long plays. > The buffer would be set back to normal default when rewinding, etc. You can't really change the size of the buffer, it's defined when you define the hw_params. You can only change the timer value. It think the 'buffer growth' you want is already handled by the concept of latency. We've also experimented with larger buffers. It's not clear to me that you really benefit from 8+ sec buffers. You have other wake-ups in the system that will reduce the benefits of long sleeps. Also as you said the timer watermark needs to take the tlength into account, a fixed initial value isn't very good. And last there is still a wake every 1.5s due to the auto-timing update. It would need to be changed to depend on the latency value. It's been on my TODO list but I still don't understand how the smoother parameters need to be changed. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate
>> I think the general idea was to stop the pops and clicks that would be >> apparent on some devices (maybe some HDA?) when the device is opened and >> closed (and also to be slightly more responsive but that's probably a >> trivial advantage on any machine made this millennium!). >> >> So I'm not sure we can idle@0s as a general rule, but as I have very >> limited test hardware (namely my laptop and couple other machine which >> aren't really meant for testing!), I can't really say this with any >> degree of confidence. > > I'll do more testing later today. I could see some issues with > networking or interfaces like S/PDIF or HDMI, where the receiver needs > to relock. But for local playback we should be fine. You will still > send zeroes out as soon as the sink-input is created, and there'll be > an interval before the first valid sample is provided by the > application. I tried with several outputs, USB headset and speakers, no clicks/pops. On the SPDIF or HDMI outputs though, my receiver does reset the DACs when it loses the sync, and there are definitely some short pops. In other words we would need to introduce a timeout value for each profile, not sure how to go about this. There's really no difference from the PulseAudio level between a USB headset that can be reconfigured and a receiver connected by SPDIF through an M-Audio USB card... -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] sidetone settings on USB headset
> In the short term a "quick fix" may be to do alsactl store 1 That did it. My default sidetone volume is now restored on hot plug and reboot. I think it's good enough, this is not something that needs to change on a regular basis. Adding support for sidetone volume in the GUI would not really make sense. It's simple enough with alsamixer/alsactl. Thanks again Colin, -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate
> I think the general idea was to stop the pops and clicks that would be > apparent on some devices (maybe some HDA?) when the device is opened and > closed (and also to be slightly more responsive but that's probably a > trivial advantage on any machine made this millennium!). > > So I'm not sure we can idle@0s as a general rule, but as I have very > limited test hardware (namely my laptop and couple other machine which > aren't really meant for testing!), I can't really say this with any > degree of confidence. I'll do more testing later today. I could see some issues with networking or interfaces like S/PDIF or HDMI, where the receiver needs to relock. But for local playback we should be fine. You will still send zeroes out as soon as the sink-input is created, and there'll be an interval before the first valid sample is provided by the application. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate
>> In my normal usage, there is a potential (solvable) problem with this >> approach, though. I use Rhythmbox and most of my songs are at 44100 Hz, >> but there are some at 48000 Hz. If I start playing one of the 48000 Hz >> songs, all subsequent streams will be upsampled to 48000 Hz till I pause >> for >5 seconds. >> >> As you suggest, this will become less of a problem if we decrease the >> idle time required before suspend, and IMO this enough to make this a >> non-blocker. > > I wonder what happens if we set the timeout to zero for ALSA devices? Arun, I just tried with load-module module-suspend-on-idle timeout=0, and it seems to work fine on the HDAudio output. I was able to switch back and forth between 44.1 and 48kHz tracks without audible issues. I am not sure what happens with Rhythmbox if you enabled the cross-fade between tracks, most likely you would remain at the rate defined by the first song. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] module-alsa-source latency is 1199291857647 ms
> My questions: > 1) The reported latency of 38 years must reflect a bug!(?) Can this be > fixed? This one made my day. Something's obviously broken here. can you provide the full log for us to figure out what went wrong? with only some excerpts it's hard to root cause. > A work-around for the moment is to bypass Pulse by running this command on > Machine2 > arecord -f S16_LE -c 2 -r 44100 | /usr/bin/esdcat # Lower latency transmit > to Machine1 > > Using Puleaudio adds 1.5 seconds in the path. But it also handles clock adjustments between your local rate and network rate. With your work-around you will have some underrun issues at some point due to clock drifts. Thanks, -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate
> Thanks for the work - this was something I was hoping to look at at some > point. I tried the patches and they do seem to work fine. Will continue > using them for a bit and see if anything goes awry. Thanks for the feedback. > In my normal usage, there is a potential (solvable) problem with this > approach, though. I use Rhythmbox and most of my songs are at 44100 Hz, > but there are some at 48000 Hz. If I start playing one of the 48000 Hz > songs, all subsequent streams will be upsampled to 48000 Hz till I pause > for >5 seconds. > > As you suggest, this will become less of a problem if we decrease the > idle time required before suspend, and IMO this enough to make this a > non-blocker. I wonder what happens if we set the timeout to zero for ALSA devices? > Unless I missed something, the only assumption I see in the code is that > one of the sample rates is a 4000 Hz multiple and the other is a 11025 > Hz multiple, so using, 88200 Hz with an alternate sample rate of 96000 > Hz should also just work. yes. The idea was to keep SRC complexity under control. > I see the sink being configured correctly for new sink inputs depending > on the sample rate of the stream, but reconfiguration to update the > sample rate of an existing stream on resume doesn't seem to be working. > I'm testing by running Rhythmbox (not using the xfade backend), playing > a 48000 Hz song, switching to a 44100 Hz song, pausing for long enough > to suspend the card and then unpausing. As far as I can tell, the move > callback isn't called on resume. That's probably a bug. I didn't try corks/resumes, so it's likely broken. Thanks again for testing! -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate
Thanks Colin for reading my prose. > Yeah, doing it server wide makes no sense IMO. The default-sample-rate > configure option predates our mixer profile logic and really (IMO) > somehow be wrapped up into card profiles or sink/source ports anyway, > but I digress. That's actually a good point. I just took the existing default-sample-rate and built on it, but yes there's no reason to have a server default value. You could have HDMI at 192kHz, no reason to prevent higher frequencies if they were available. >> - To avoid quality issues, I limited the sinks to two frequencies, >> 44.1 or 48kHz. If we allowed for lower sampling rates, it'd be a >> problem if additional sink-inputs/source-outputs are created at a >> later stage with a higher sampling rate. This means that for a phone >> call or voice memo you would still see a resampling, but it should be >> lighter with integer instead of fractional ratios. > > While I see the logic behind it, it'll likely not placate all those > people who want dynamic rate switching. Perhaps this will need to be > extended at some point but perhaps it's a sensible starting off point. > I'm thinking more of even larger frequencies rather than lower ones > (although the practical usefulness could obviously be debated endlessly) Humm, I didn't follow your thinking here. >> - the sinks/sources only get suspended after a 5s timeout. This seems >> too high for sinks/sources that can be reconfigured quickly. It may >> make sense to have different values for the timeout, and make them >> dependent on the configuration latency. > > Or perhaps the "OK to change rate" logic could work when the sink is > either IDLE || SUSPENDED ? That way the suspend timeout wouldn't really > matter. Just a thought. I have more work to do on IDLE. This typically happens when the sink-input is corked, so you could add an SRC if for some reason the rate was changed. Even in the SUSPENDED case my USB headset seems to complain... > One thing I think would be very interesting here would be cards that > support hardware mixing. > > With these cards, would it be possible to open a stream for each of the > different rates we want to use? Then when we deal with the mixing, we > mix all the like-rated inputs together and send those separately to > their matched device-stream? > > That is likely the best use of such hardware and the best implementation > of support for multiple rates, but it's possibly not worth thinking > about immediately due to the fact that this h/w is likely in a minority. I can see cases where you have 1 compressed stream and 1 PCM, and you mix the two in hardware, but I am having a really hard time finding a use case where you would have multiple (more than 2) PCM streams at different rates. Maybe automotive cases, where the infotainment unit might send multiple streams to a head unit were the mixing/routing is actually done? Did anyone request hardware mixing on the mailing list? -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] State of various rate adjustment patches
> I've tested module-loopback by playing to a null-sink and looping its > monitor to the real alsa sink. This showed good behaviour, but may be > the algorithm I used for module-rtp-recv should also be used here. > Does anyone has a better suggestion for a setup to test > module-loopback? null-sink and alsa have very stable latencies, so its > no good test for module-loopback. To test the loopback, what I had in mind was enabling a BT sink (receving data from somewhere else using A2DP) and playing locally on the speakers. That should trigger all kinds of latency issues since the transmitter essentially pushes packets without worrying too much about time, and the receiver has to do all the synchronization work. Should be fairly easy to enable by modifying the /etc/bluetooth/audio.conf, but I haven't had the time to test so far -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] sidetone settings on USB headset
Hi, I have a nice USB headset that I use for VoIP calls. It does insulate a great deal from my noisy colleagues, but as a result I have to tweak the sidetone gain to hear my own voice (most headsets provide the capability of looping the mic input to the speakers with almost no latency). I can play with the 'Mic Playback Volume' in alsamixer, but I have to do this everytime I plug the headset. alsamixer doesn't remember the value, nor does pulseaudio. Pulseaudio only stores the 'Mic Capture Volume' and the 'Speaker Playback Volume' (I found the names by playing with the values in alsamixer to set the sidetone gain to the max and zero the capture gain, see below) Any idea on how I can record my preferred setting once and forall? Is this best done at the pulseaudio or alsa level? Thanks -Pierre $ amixer -c1 contents numid=1,iface=MIXER,name='Mic Playback Switch' ; type=BOOLEAN,access=rw--,values=1 : values=on numid=2,iface=MIXER,name='Mic Playback Volume' ; type=INTEGER,access=rw---R--,values=1,min=0,max=464,step=0 : values=464 | dBminmax-min=-41.00dB,max=-12.00dB numid=5,iface=MIXER,name='Mic Capture Switch' ; type=BOOLEAN,access=rw--,values=1 : values=on numid=6,iface=MIXER,name='Mic Capture Volume' ; type=INTEGER,access=rw---R--,values=1,min=0,max=13,step=0 : values=0 | dBminmax-min=16.00dB,max=29.00dB numid=3,iface=MIXER,name='Speaker Playback Switch' ; type=BOOLEAN,access=rw--,values=1 : values=on numid=4,iface=MIXER,name='Speaker Playback Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=44,step=0 : values=44,44 | dBminmax-min=-41.00dB,max=3.00dB ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Rethinking rate adjustments [was: Re: [PATCH] module-combine: limit the size of the rate adjustments]
>> Any idea what the sample rate drops linearly in the initial part? >> Maybe we ought to prevent SRC adjustments until there's enough history >> to make such changes? >> -Pierre > > Thats because initially the buffer with audio from the RTP stream only > contains about 270 ms worth of data. To get this up to the desired > (hardcoded) value of 500ms, the sink-input reading from this buffer > has to be slowed down a bit. To get it up to 500 in about half a > minute would require the sample rate to be around 47300 Hz, but > instead of jumping directly to this value, the rate is gradually > decreased a factor 0.998 to avoid audible artifacts. This lead to a > wedge in sample rate and a nice S-shaped curve in buffer latency. > > The adjustment should not be delayed, because the low buffer should be > filled as soon as possible, to reduce risk of underrun. Also the > estimated "real" sample rate (not shown in the graph) is already > accurately determined very soon. In my case the RTP stream clocks in > at 48006 Hz. Couldn't silence be played initially? It seems weird to me to change the sampling rate to compensate for missing data. Resampling should compensate for clock drifts. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Rethinking rate adjustments [was: Re: [PATCH] module-combine: limit the size of the rate adjustments]
> The third shows the new algorithm. Doesn't it look pretty? The event > halfway (after two minutes of playing) is change of song. Apparantly > this introduces some extra samples in the RTP stream, but the > algorithms deals nicely with that. > > The new algorithm does not seem to work well for module-combine, so as > it stands I would only do the clamping of the rate adjustments there > and not the algorithm change, just like the patch I send earlier in > this thread. I still have to look into module-loopback, but I guess it > will be similar to either module-rtp-recv or module-combine. Any idea what the sample rate drops linearly in the initial part? Maybe we ought to prevent SRC adjustments until there's enough history to make such changes? -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] module-combine: limit the size of the rate adjustments
Hi Maarten, > In the attached piece of log output this can be clearly seen. The rate > of the stream for the null-sink varies between 47300 and 48700. I > think this is because every time module-combine wakes up to look at > the latencies of the slave sink inputs, it finds the null-sink with a > different latency. I'm not sure how to fix this, may be some sort of > avering (or even a smoother on the latency for each slave sink input) > > Another way of fixing it (at least getting rid of the symptoms) is by > limiting the adjustments module-combine is doing every 10 (by default) > seconds. The attached patch does this. The patch is roughly the fix > proposed in http://pulseaudio.org/ticket/288 Yes the same issue happens with the loopback when capturing data from BT or some RTP source. The latency on a standard ALSA device varies less wildly but the adjustments are still arguable in terms of audio quality. I posted a rate adjustment as well a while ago which was never merged, but that's not enough. We'd need some averaging to prevent jittery adjustments. It's been on my TODO list for some time but if you want to go ahead feel free :-) -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate
Happy New Year, During a set of long-haul flights and long waits in airports, I tried to address one of the recurring concerns listed on this mailing list, namely the somewhat high CPU usage due to resampling. In most cases people will listen to music at 44.1kHz. watch movies at 48kHz, or start a voice call at 8 or 16kHz. Running the sinks/sources at a fixed default frequency isn't going to be optimal for all cases. To work-around this limitation, I introduced a new callback for sinks and sources which can be called to reconfigure the sampling rate. It works fine on my laptop. However there are a number of limitations on which I'd like to have comments before moving forward: - first the change is only possible when the sinks/sources are suspended. I made this conscious decision to avoid glitches. PulseAudio runs as a daemon, in most cases the sinks/sources are suspended when the user want to hear something. - I decided to have a per-sink/source implementation, and to make the feature optional. In the case of Bluetooth or other network protocols, tearing down the link and reconfiguring it may be too long. This reconfiguration is nearly immediate for a regular ALSA sink - To avoid quality issues, I limited the sinks to two frequencies, 44.1 or 48kHz. If we allowed for lower sampling rates, it'd be a problem if additional sink-inputs/source-outputs are created at a later stage with a higher sampling rate. This means that for a phone call or voice memo you would still see a resampling, but it should be lighter with integer instead of fractional ratios. - Some work would be needed to prevent system alerts from reconfiguring the sampling rate, but this is a different policy-related problem. - the sinks/sources only get suspended after a 5s timeout. This seems too high for sinks/sources that can be reconfigured quickly. It may make sense to have different values for the timeout, and make them dependent on the configuration latency. Please review the code, give it a try and let me know if you think this is a useful feature to add. Thanks, -Pierre 0001-core-add-support-for-alternate-sample-rate.patch Description: Binary data 0002-core-dynamic-change-of-sampling-rate.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] [module-loopback] Add new arguments sink_dont_move and source_dont_move to toggle module automatic unloading when the sink or source were not available
On Thu, Dec 23, 2010 at 5:40 AM, Cai Yuanqing wrote: > This patch add two new boolean arguments sink_dont_move and > source_dont_move into module-loopback,so we can make the module unloading > when the sink or source was unavailable. > To enable this feature we can do something like: load-module module-loopback source=bluez_source.00_22_A5_AA_BF_85 sink=alsa_output.pci-_00_1b.0.analog-stereo source_dont_move=TRUE > > And you can just feel free to ignore these arguments. I don't have any arguments against the source_dont_move, but I am concerned about the sink_dont_move part. You may want to listen to your music on speakers, headsets, HDMI, etc. Why would you restrict the playback to the sink selected when you loaded the module? I can see this interfering with the accessory management/audio policy, at least in Meego. Falling back to the default sink should not add any noises? -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/3] Fighting rewinds
>>> However, the problem is quite complex and there does not seem to be one >>> perfect fix, it's more of an optimisation problem. GStreamer in >>> particular >>> sends out many small data packages, and PulseAudio does not handle that >>> very >>> well. >> >> That's the default behavior, but you can cut the traffic by using the >> latency-time property in pulsesink. This makes sure you send bigger >> buffers, up to the 64k limit that PulseAudio has internally. > > Thanks, that's good to know. Now, I'm just playing a simple audio file with > totem, so obviously we want high latency and large packet sizes, but I'm not > a gstreamer developer - do you have an idea of what can be at fault here? > Should totem specify a big packet size (regardless of sink?), or can we just > change the default packet size to something big for people not requesting > anything in particular? The default pulsesink settings for latency/buffering are inherited from a base class. I would agree with you that they should be large by default and decreased explicitly when the application wants low-latency (gaming, speech), but the opposite is done... It's my understanding that higher-level components in the Meego/Qt stack will specify bigger buffers/higher latencies, but for people who use plain vanilla gstreamer optimizing for power requires a bit of knowledge and manual configurations. This is unfortunate since every single player will need to repeat this configuration. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/3] Fighting rewinds
> However, the problem is quite complex and there does not seem to be one > perfect fix, it's more of an optimisation problem. GStreamer in particular > sends out many small data packages, and PulseAudio does not handle that very > well. That's the default behavior, but you can cut the traffic by using the latency-time property in pulsesink. This makes sure you send bigger buffers, up to the 64k limit that PulseAudio has internally. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Latency control for wine ALSA emulation?
>> I'd rather not hardcode tsched=0 because I'm on a laptop =). Please let >> me know what other things I can do to debug, would a log be helpful >> (since the issue is pretty certainly the latency control), or should I >> get a wine log instead. That would probably be a waste of time since >> winealsa isn't maintained currently I believe. if you want to use tsched, can you experiment with a buffer size that works for you? module-alsa-sink can take the following parameter: "tsched_buffer_size= " -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Supporting hardware resampling
> Specifically, there is a dedicated DSP on board that can resample, > multiplex and output audio. The ALSA driver actually uses this DSP, > but Pulse Audio is stuck resampling and muxing in user land before > passing data to the ALSA driver. I've been browsing around source and > documentation, and while it seems straightforward enough to create a > sink module that will dump PCM samples to the DSP, it does not seem > that this would be sufficient as incoming samples to that sink would > be resampled to match its parameters. > > Is there some way to make a more generic sink that can take multiple > sample rates and pass data through? Is this something that may > require a card and sink combination instead of just a sink? Or maybe > I should just ask is this possible without major changes in Pulse > Audio's architecture? Default PulseAudio behavior is to mix in software. If you wanted to mix in hardware, you could highjack the passthrough work I've been doing for AC3. Essentially one device for sw mix, and a number of hw devices with no processing in PulseAudio. Still fairly hairy stuff at this point since you need to tag each stream as passthrough or not, and route explicitely to a specific device for hw or sw mixing. You would also need to load these devices by hand in the default.pa configuration or use a specific profile for your hardware. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] dynamically changing alsa sink/source sampling rate
> I think that would solve the (or my) most common use-case (imho): > > play music (usually 44100hz) > stop music > play movie (usually 48000hz) > stop movie > (rinse and repeat) Yeah, I am only talking about 44.1 and 48 changes. All the other frequencies can be resampled fairly easily. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] dynamically changing alsa sink/source sampling rate
> I wont say it will never be supported (if someone writes a well formed > patch that doesn't introduce any significant complications/overhead then > I can't see any problems with merging it), but I doubt any of the main > developers or companies supporting PA will want to do this any time soon > (although I could of course be wrong here). It's on my radar, this is a change that is required for compressed data support, and while we are at it we could modify the behavior for PCM as well. Jyri seemed in favor of this as well on the Nokia side. What I had in mind is that changes in sampling rates would be allowed only if a sink/source is inactive and the actual hw device closed, and only if the application has a role where such a change makes sense. That would enable low-power use cases without requiring resampling. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] alsa: remove redundant call to snd_pcm_nonblock()
Inconsistent use of ALSA. The non-blocking behavior is defined either with SND_PCM_NONBLOCK when the handle is opened, or later with snd_pcm_nonblock(), Using the two solutions doesn't make sense. Not sure why the code was written this way in the first place. Probably a miss when Lennart modified this file with 84ade2140ed44bf241eda494d0970390e48b21d3 -Pierre 0001-alsa-remove-redundant-call-to-snd_pcm_nonblock.patch Description: Binary data ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] MP3 passthrough over A2DP (2nd version)
Here's the corrected path with most comments from Tanu implemented. I attached some additional gstreamer patches so that people can test the actual functionality. -Pierre 0001-bluetooth-MP3-passthrough-over-A2DP.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] bluetooth: MP3 passthrough over A2DP
Thanks for the reviews. I will resubmit the patch later this week. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] bluetooth: MP3 passthrough over A2DP
Thanks Tanu,
couple of comments on your review:
- I did spent a lot of time correcting these spaces, but there's
always some that go through. If anyone had a indent configuration,
it'd be simpler to review patches having the same style... That's what
gstreamer does. I'' fix those by hand but it's a pain.
> Should this be put a few lines earlier, before "if (codec->configured &&
> seid == 0)"? If we return codec->seid, this function will be called
> again once, but is it possible that also the second invocation will
> return codec->seid? If it's possible, then u->a2dp.has_mpeg is left as
> FALSE, which is probably wrong.
No the code is called twice and the second time with an seid different
from zero. Only when the second call succeeds do you want to record
this endpoint as a valid one.
>> + pa_log("setup_a2dp: Trying to set-up A2DP Passthrough
>> configuration but no MPEG endpoint available");
>> + return -1; /* this should not happen */
>
> Please use assertions for stuff that should not happen. That makes it
> much easier to reason about the code - if there's no assertion, the
> reader has to assume that it actually is possible that this code is
> executed in some situation, and if the reader wants to know what
> situation that would be, it may take a significant amount of work to
> figure out that in the end the code can not really be ever executed. The
> assertion is a promise that somebody else has already done that
> checking. Having just a "this should not happen" comment looks like the
> author of the code isn't quite sure whether proper error handling is
> required or not.
I guess the comment is wrong. no need for an assert.
> Time to revisit the sample vs frame discussion... I'm sorry I never
> replied to your last mail concerning this. I'll reply now.
>
> You wrote:
> "It's actually number of samples. Frames only makes sense for PCM, for
> compressed data what you need is the number of samples. Frames are
> undefined for compressed data."
>
> I'm fairly sure "pcm frame" means something else to you than to me. If
> the sampling rate of a pcm stream is 48000 Hz and the stream has two
> channels, then one second of that stream contains 48000 pcm frames and
> 96000 samples when using my definition of terms "pcm frame" and
> "sample". I guess you would say that one second of such stream contains
> 48000 samples and some smaller number of pcm frames - I don't have an
> idea what the definition of "pcm frame" would be in this case.
- on the samples/frames discussion, this is just a matter of wording.
People with a DSP background will use samples because that's a concept
they can relate to. There's no such thing as a framing frequency...
Frames are used by people with a CS background who don't understand
what the sampling theorem is.
> There already are functions pa_sample_size() and pa_frame_size() that
> follow the terminology I'm advocating. The audio APIs that I'm familiar
> with use the same terminology: alsa has types called snd_pcm_uframes_t
> and snd_pcm_sframes_t and jack has jack_nframes_t.
That's valid for PCM only.
> It's possible that there was no misunderstaning, and you're really
> claiming that compressed data doesn't care about pcm frames, but I very
> much doubt that...
>
> So, how about renaming this array to pcm_frames_per_mpeg_frame?
If that makes you happy I'll do the change, but this is clearly a
wrong interpretation. You want to infer the length of a frame in ms by
dividing the sampling rate by the number of sample points...
> Fix spaces. Also, you use constant index 1 - that's wrong for < 32kHz
> streams, isn't it?
I have to check this one, can't remember why this was done this way.
>> + if (preambles == 0x72F81F4E) { /* little endian assumed *
> Where is this magic number specified? What document should I read in
> order to understand and verify this code?
IEC958 standard.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Add a new target to Pulseaudio log feature
> I would like to add in the log feature of PA a way to log(redirect) > ‘pa_log_*’ messages in a file, which can be a char device for ex. That means > adding a target to the log of pulseaudio. This target is not settable yet > and I made changes in Pulseaudio for enabling a new log target of file type. Can't you just configure the setting below in client.conf? ; extra-arguments = --log-target=syslog -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] disabling monitor source patch
>> As part of the passthrough/compressed data support in PulseAudio, we >> need to disable monitoring. The main use of monitoring is to build >> peakmeters to show volume information, and that just doesn't make >> sense for compressed raw data > > I have also been using it several times to record things as streaming music, > skype conversations etc. So I would say that the peak meters are not the > only main usage of monitoring. > > Also, we always have a sink and a source, because of module-auto-sink that > adds a null sink (and a monitor of that) if no sinks exists. If we end up > having no sources at all, would that open up a can of worms? > > I would say to go with keeping the monitoring source - either decode it, > leave the raw data as it is, or write zeroes, whatever we conclude is the > best way to go. Just to be clear, what I am proposing is to disable monitoring sources only for the case where a sink supports compressed data. Null sink doesn't so there's no change of functionality. You could push silence instead, but that's a pretty much a waste of resources; I don't see any need for monitoring for compressed data at all for a pass-through mode... If you need to decode, it has to be done upstream. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [RFC] disabling monitor source patch
Hi, As part of the passthrough/compressed data support in PulseAudio, we need to disable monitoring. The main use of monitoring is to build peakmeters to show volume information, and that just doesn't make sense for compressed raw data I started disabling the monitor sources, but I found out some isses with the specific modules (dbus interface, http protocol, rygel server), where I could use some help. I have no idea what these pieces of code do and what the behavior should be if there is no monitor source for a specific sink. These isssues are highlighted with FIXME in the code. Thanks for your feedback, -Pierre disable-monitoring.patch Description: Binary data ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Routing of audio to loudspeakers or headphones
>> For jack sensing, we'd need a module that traps input events. ALSA >> sends an input event when the headphone jack is inserted. This is >> what's used in Meego (the detection isn't part of PulseAudio though). >> You could then add enable the effect. >> -Pierre > > Could you tell me where (in which source code file) I can find this detection > in > Meego? It's part of the Ohm plugins. http://meego.gitorious.org/maemo-multimedia/ohm-plugins-misc/blobs/master/plugins/accessories/wired.c I am not sure this code is current, someone from Nokia would need to comment But you'll see all kinds of jack detection in there. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Does PA have sound effects like SRS Sorrounding, 3D Spatializer, sound enviorment emulation etc?
> Does anybody know that if PA has sound effects like SRS Sorrounding, > 3D Spatializer, sound enviorment emulation etc? > > Or is there any above sound effects solution under Linux? PulseAudio has support for LADSPA, you can plug effects of your choice. Check out http://www.ladspa.org/ There are some limitations as the effects are applied after mixing, I am not sure you can apply a per-stream effect before mixing. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] New dependency: Orc
> I've been doing some work optimising the software volume scaling code, > and along with my previous changes to decrease the maximum volume to > 2^31-1, there seems to be a pretty good performance increase (almost 2x > on my Core2 processor). Are you saying you have a 2x performance gain over sse assembly? That would most likely mean we need to fix the assembly for x86 and have an even better performance than with orc and its intermediate step of SIMD code generation... -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] volume: Fix incorrect usage of PA_VOLUME_IS_VALID
On Tue, Oct 19, 2010 at 3:56 AM, Colin Guthrie wrote: > 'Twas brillig, and Arun Raghavan at 19/10/10 08:33 did gyre and gimble: >> The commit that introduced this macro was incorrect in some places. This >> patch fixes these. Thanks to Pierre-Louis Bossart for pointing this out. > > I thought I'd looked over all the cases where this was used to spot > these as I was mindful that this could have been a problem easily > introduced with this kind of change, but clearly I didn't do a good job. > So much for that :s > > I've pushed this patch now as it's very obvious from looking at the > changes that it's needed. > > Would be good if it did solve all of Pierre's issues too. This patch corrects the issue I reported. Thanks Arun. However I am now having problems with my multichannel files even when the same volume is applied for all tracks constant high frequency noise...more git bisect ahead of me... -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Broken volume control
Looks like the volume control logic has taken a big hit, when I move the volume up and down with the slider on the Output Devices tab in pavucontrol, I have _huge_ pops and clicks, the volume goes to zero in the playback tab. Git bisect flags the following patch and I manually confirmed that this patch introduces the noises. Arun, can you look into this? I noticed that there are some inconsistencies on the use of !PA_VOLUME_IS_VALID, sometimes the ! is missing. Thanks, -Pierre $ git bisect bad 49101fc540aec9a249e97a9f650be38f9f92f5ac is the first bad commit commit 49101fc540aec9a249e97a9f650be38f9f92f5ac Author: Arun Raghavan Date: Sat Oct 9 15:38:43 2010 +0530 volume: Clamp volume to PA_VOLUME_MAX This ensures that we always clamp the volume to PA_VOLUME_MAX. While this currently has no effect, it will be required for making sure we don't exceed PA_VOLUME_MAX when its value changes in the future. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Noise when setting volume of individual tracks w/ multichannel files
Hi, I tried to see if the latest changes in git master to the volume control code fixed a bug I noticed some time ago. No luck. When playing a 6-ch file, if I change the volume of, say, the front left with pavucontrol, a noise appears. As soon as one volume setting is different (higher or lower) from that of the other channels I hear this noise. If the volume changes for all channels at once, the noise disappears. I don't really understand the volume control code, but I wonder if this can be confirmed by others? -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes
>> There's no real way you can extract timing information just by looking >> at the data. You either need to parse the frames (what I did for the >> BT work) or let the hardware report the number of samples it decoded >> and rendered. In both cases, you could find out what the average bit >> rate is and have an approximate idea of the relationship between the >> numbers of bytes passed to pulseaudio and the duration. It would be a >> bad idea though to rely on this approximated bitrate to infer timing. >> The client should get the audio time as reported by this sample count, >> not through inversion of an approximation that will only be correct >> for constant bit rates. Instead of basing all time ports on >> GET_LATENCY messages we should really have a new GET_TIME message. > > Why can't the encoded data for MP3 be handled the same way as DTS/AC3 over > spdif/hdmi? They are preformatted with a iec958 header and padded with zeroes > to > the correct sample length given samplerate and channel count. > > To padding and adding of this header is up to the application. Now if a2dp > supports mp3 as a raw format can't the a2dp code in bluez or whatever is > communicating with the a2dp device strip the header. > > This way timing through pulse remains simple.. That's exactly my plan. I experimented with raw frames and it turned out to require too many changes. So yes the Mp3 stream would be reformatted as an IEC61937 format, and the pulseaudio sink would indeed strip the additional header and padding. The issue is that you can have different IEC61937 formats, and I would like to have additional information passed rather than the existing 'passthrough' flag. This is mainly need to make sure you link a sink_input with a sink that supports the relevant format. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] AC3 passthrough support
>> > To use this feature from other frameworks (gstreamer, etc), we will >> > need a tagged release to #ifdef code related to AC3 passthough for >> > backwards compatibility. Any idea when that might happen? >> > (would also be nice to close the gap between git master and meego >> > versions while we are at it...) > > > What's the status on this? Is it usable and #ifdef able? This would be damn > good > news for us (xbmc). I am planning some changes to the existing patch. The current solution only uses a 'passthrough' flag, but you would need additional information to pass format information so that you can pass MP3 to play over BT headset, or AC3 over HDMI. Today this isn't possible with a boolean only. I am not familiar at al with XBMC, if you have specific requirements or ideas, they are welcome at this point. I only looked at the problem from a gstreamer perspective. The main idea so far is to try and use the passthrough mode, and if the connection fails (no support in hardware or audio policy), then you would fall back to software decode. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 2/2] mp3 passthrough: Bluetooth changes
Thanks Tanu for your review. Here are some replies on the comments not
related to formatting. There's a nice idea on passing frame-aligned
data in memchunks that looks interesting, this is valuable feedback.
-Pierre
>> + uint64_t s_read_index, s_write_index; /* count in samples instead of
>> bytes */
>
> The unit seems to be actually pcm frames, not samples.
It's actually number of samples. Frames only makes sense for PCM, for
compressed data what you need is the number of samples. Frames are
undefined for compressed data.
>> + codec = (codec_capabilities_t *) rsp->data; /** ALIGNMENT? **/
>
> codec_capabilities_t contains only 8-bit variables, which to my
> understanding guarantees that it doesn't matter where the data happens
> to be located in the memory. If you agree (I don't consider myself an
> alignment expert), then I suggest you remove the "ALIGNMENT?" comment
> from here and from parse_caps.
This is code I copy/pasted from the existing code...No idea if there's
a problem here.
>> + u->a2dp.has_mpeg = has_mpeg;
>
> As far as I can see, the local has_mpeg variable is redundant; you can
> use "u->a2dp.has_mpeg = TRUE" here.
Right
>> + /* vbr - we always say its vbr, we don't have how to know it */
>> + mcap->bitrate = 0x8000;
>
> I'm not sure what "we don't have how to know it" tries to say.
This is taken from the mpapay element in gstreamer. What this is
saying is that bitrate doesn't really matter.
> Also, does every BT device that supports MP3 support VBR?
They should. This is indicated in the endpoint capabilities. I don't
have any headset that doesn't support all valid rates.
>> + pa_log("setup_a2dp: Trying to set-up A2DP Passthrough
>> configuration but no MPEG endpoint available");
>> + return -1; /* this should not happen */
>
> If it happens anyway, can the bug be anywhere else than in Pulseaudio's
> code? If not, use an assertion.
No, in that case the profile is not loaded.
>> +
>> + /* FIXME : number of samples per packet */
>> + u->samples_per_block = 1152;
>
> So is this assuming certain link_mtu and certain constant (or average)
> bitrate? Since the samples per block ratio doesn't stay constant with
> vbr streams, is this variable going to become unneeded when you
> implement the timing logic correctly?
The issue is more that the mp3 frame is 576 samples below 32kHz, and
1152 above. This was the meaning of my comment.
>> +static int a2dp_passthrough_process_render(struct userdata *u) {
>
> I think you should add "Run from IO thread" comment here. I know
> a2dp_process_render() doesn't have the comment either, but I think it
> should.
Right
>> + /* inits for output buffer */
>> + a2dp_prepare_buffer(u);
>
> Not really related to this patch, but I checked a2dp_prepare_buffer
> implementation, and it seemed broken: it sometimes calls pa_xmalloc()
> from the IO thread. Fixing that doesn't belong this patch, though. I
> just thought I'd mention. Someone should fix that, but it's a completely
> separate task, so there's no reason that someone should be you...
yes, I also didn't understand why the buffer is 2x larger than needed.
> I suggest you do the parsing of the mp3 frames as soon as possible, i.e.
> in pa_stream_write(), and drop the data that you can't parse
> immediately. That way there will never be gaps when the data is
> processed in the server (the server must still not crash if such gaps
> are found, in case the client is using something else than libpulse to
> communicate with the server).
>
> I also suggest that you make sure that memchunks contain only whole
> frames. That way it's always possible to map a memchunk's data to time,
> and also map a memblockq's data to time. I would guess that those
> mappings will be needed.
It's assumed that some level of parsing is done before going into
pulseaudio (such as mp3parse in gstreamer). I initially through I
would only pass bytes through the pa_stream interface. But maybe you
are right, passing frame-aligned binary data with additional fields
such as type and length would make my life simpler. This is an
interesting idea, let me think about it. That could avoid some of the
timing issues and API breakage we are facing otherwise.
>> + header->m = talk_spurt;
>
> talk_spurt is a redundant variable. You can use simply header->m = 1
> here.
Yes. I used to set this variable only when a first sync word was
found, as explained in the RTP spec, but apparently it's set to one
all the time in the mpapay implementation.
>> + header->sequence_number = htons(a2dp->seq_num++);
>> + header->ssrc = htonl(1); /* should in theory be random */
>
> Why should it? And why is it not? What are the consequences of this
> choice?
In the RTP spec, it is recommended that the ssrc be random for each
session for additional security. In the BT case, this is really not
that important.
>> if (audio_sent <= time_passed) {
>>
Re: [pulseaudio-discuss] [PATCH] BlueZ Media API
> Note: This probably conflicts with Bossart's patches so we probably need to > rebase once we find out which one should get in first. My patches are not in a state where they can be merged in git master. You go first... -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] 61ms delay in pa_simple_write()
> For normal alsa playback, their typical values are 1024. Pulseaudio > sets them to large values and maybe is not entirely depending on the > poll. It may be setting some timer to wake up itself when the DMA > buffer runs low on data. > > Anyway the pulseaudio's large buffer scheme makes possible the 61ms > pa_simple_write(). Qemu is not expecting such a large latency. Its > QEMU_PA_SAMPLES defaults to 1024, which can only hold up to > 1024/48=21ms samples. So the 61ms delay will obviously overflow the > "data push" based USB audio model.. The default PulseAudio configuration is 4 periods of 25 ms each. You can reduce this if you want by changing the relevant fields in /usr/etc/daemon.conf -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] 61ms delay in pa_simple_write()
Hi Fengguang, > Hmm it seems there are zero memory allocation delays, so it's at least > not the root cause of the qemu delays in my case. Can you run a sanity check with the tsched=0 option at the end of the module-udev-detect line in your /usr/etc/default.pa file? This will disable the use of timers and instead use the ALSA period events to wake-up the real-time thread. PulseAudio will then behave as a traditional ALSA front-end. If this works, then it means the logic behind the timer-based scheduling fails in your system. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [RFC] stream API extensions to support compressed data
Here's a first proposal that I think avoids major disruption in the development. Two new routines are added to specify the pa_stream will transport non PCM data. This new extended type will be passed through the native protocol instead of the 'passthrough' flag I added earlier, and all sinks/sink-inputs/sources/source-outputs on the server side will make use of this extended representation. It'd be nice to have a means to query what the sink capabilities are before creating a stream with a non-PCM type, but you don't know on what sink you will play until you actually connect and server-side heuristics/audio policy kick-in. The expected behavior on the client side is that if the connect_playback call fails with compressed data, the application will have to reconfigure its pipeline to provide PCM data and retry. The simple API remains simple and handles PCM only. Feedback welcome -Pierre stream-api.patch Description: Binary data ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes
> I fully agree, except that I don't understand what's wrong with > GET_LATENCY. AFAIK, GET_LATENCY returns the time that it will take for > the next sample that enters the system to get out of the speakers. How > would GET_TIME differ from GET_LATENCY, and why would it be better? GET_LATENCY finds out how many bytes are currently buffered, and once you subtract this from the number of bytes sent to PulseAudio you get the number of bytes played. Dividing by the sample size gives you the audio time. A GET_TIME message would fetch the sample count straight from the sink, no matter how much was buffered, and no matter what type of data you handle you can convert to a time value if you divide by the sampling frequency. If there's no mixing the two messages are equivalent for PCM data. Cheers, -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes
> Annoyingly, no I don't have list rights... I asked a while ago, but no > reply :( Oh well, I will rework the patch and repost it in a couple of days... > It was my understanding that Lennart wanted to have some way to extract > timeing infromation from compressed codecs etc. to allow for wakeup > times to be calculated properly. I'm not sure if the usec conversions > need some kind of supplement for compressed formats? I suspect however > if timing information is to be extracted successfully from these > formats, we'd need to know which format it actually is. > > Your suggestion seems reasonable, but not sure it can be used without > API breakage (e.g. the extra subtype information?). I've not really > looked to closely so this may not be an issue at all. There's no real way you can extract timing information just by looking at the data. You either need to parse the frames (what I did for the BT work) or let the hardware report the number of samples it decoded and rendered. In both cases, you could find out what the average bit rate is and have an approximate idea of the relationship between the numbers of bytes passed to pulseaudio and the duration. It would be a bad idea though to rely on this approximated bitrate to infer timing. The client should get the audio time as reported by this sample count, not through inversion of an approximation that will only be correct for constant bit rates. Instead of basing all time ports on GET_LATENCY messages we should really have a new GET_TIME message. In terms of API changes, for the passthrough work I managed to avoid any breakage with an additional flag. I think if we change the pa_sample_t and add new fields, we will break everything. Maybe we can change the API in a backwards compatible mode, where we use a pa_sample_extended_t if this flag is set. The native protocol would need to change no matter what, but if this is hidden in libpulse we should be good, right? Cheers, -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes
>> Again, unless there's a good reason not to, I'd put >> pa_assert(spec->format != PA_MP3) here. > > If the plan is to add other codec support longer term, then perhaps a > function is better? > > e.g. > > pa_assert(!pa_format_is_compressed(spec->format)); > > That way others can be added more easily in the future? > (not sure if this is a concern or if PA_MP3 would be better named as > PA_ENCODED_DATA, but my guess is that some kind of timing information > will eventually be extracted from MP3 streams to control processor wake > up/sleep times etc, and thus individual encoding systems would have to > be identified separately as is currently with PA_MP3) That was one of the points I listed. If we start adding support for AC3, DTS, MP3, AAC, we will never cease updating these files. I would be better to signal that the format is ENCODED, meaning all the bytes to usec conversions used for PCM do not apply, and have a second structure that would list the type and possibly contain some parameters required by the decoder. It looks like my main patch was not published since it's slightly over the size limit. I did make a lot of changes in the module-bluetooth-device code, not sure how I can break those in pieces. Does anyone have admin rights to let it through? Thanks. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
>> So what does this test mean? pavucontrol obviously affects the latency >> of the sink due to it's VI meters. This obviously increases the >> likelihood of a rewind being triggered.So, with this in mind what >> values do you suggest we pick? > > Pierre, is it your understanding that it is when DMA transfer collides with > cpu->RAM transfer that makes the DMA stream to become broken permanently? Or > exactly what is it that makes it break? The low-latency setting has nothing to do with rewinds. It's when you actually change the volume that you will rewind and remix with the new stream volume. You could set a super low latency and rewind exactly once when the stream starts. There are two issues with the rewind. One is a race condition between the DMA and the ring buffer update. If you rewind and update the ring buffer, the DMA may actually have already fetched older data. The second is that you could experience underflows if you don't do the update fast enough. By enabling logs you should be able to find out if there are real underflows. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
> Agreed: You can pick those two patches, and then we add a third patch to > both branches, which brings back the watermark for tsched devices and 20 > ms for non-tsched. Assuming my suspicion is not disproved, of course. > What does Pierre think of that? I don't want the watermark to be used for rewinds. The watermark is there for timer-based scheduling, so that you have enough time to wake-up from sleep and still refill the buffer. The rewinds happens when the processor is already awake, pulseaudio up and running and only the remix part needs to happen. Plus the watermark varies and the logic could really be improved. Also I think 20ms for rewinds is way too much. This will kill your actual latency. Imagine you have a low-latency app that starts, the first sample would be heard after at best 20ms. Not acceptable for speech or interactive sounds. But I agree that 256-bytes isn't fool-proof for heavy duty use cases such 8ch 192kHz 32-bit float. So how about we keep 256 bytes (1.33 ms for 48kHz) but add a 1.33 ms threshold to make sure we never rewind below. rewind_safeguard = max(256, pa_usec_to_bytes(1330)); This way you solve both the hardware issue (frequency independent) and leave enough headroom for the system to avoid underflows. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
>> Probably either one will work, but if we're about to release 0.9.22 >> (heard something from Lennart yet?), I suggest we go with my version for >> 0.9.22 as that one is the least invasive (only touches non-tsched >> devices), and keep Pierre's version in master. > > Sounds reasonable. Pierre, what's your take? That would mean an additional post-release patch for tsched devices. I am lazy and would prefer a one-stop fix. I don't care if this is David's or mine, as long as the solution works for both cases. The only real difference is the bytes/ms parameter. Although ms are more intuitive, the bytes makes more sense from a hardware point of view. If you pass a parameter in ms, there might be cases where the actual number of bytes is lower than the DMA burst, it'll depend on what frequency the sink operates at. There are some cases where alsa-sink works at 8kHz (BT-SCO) or 48kHz (all other cases), a 6x variability in the rewind behavior is difficult to handle. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Routing of audio to loudspeakers or headphones
> Even when this is all done, you will still not get everything working > 100% perfectly just yet. Jack sensing is (apparently - not looked for a > while) a mess and does not work reliably on all drivers. We need to fix > that and probably will enable automatic port switching on jack status in > due course. But until this comes in, when you plug in your headphones, > you have to manually change the port in pavucontrol (labelled connector > in gnome tools). For jack sensing, we'd need a module that traps input events. ALSA sends an input event when the headphone jack is inserted. This is what's used in Meego (the detection isn't part of PulseAudio though). You could then add enable the effect. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ALSA sink enumeration and multiple devices/subdevices
> In practice, NVIDIA GPUs only support sending video signals over at most > two of these connectors at once, and hence the HD audio controller only > allows two audio streams to be configured at once. The exact set used can > be dynamically reconfigured by changing xorg.conf or using NVIDIA's tools > to manipulate a running X server; similar to xrandr. Ok, so now I understand your need to have multiple devices on the same card. Point taken. I am still not clear on the need to expose 4 devices, out of which 2 are known to be non-functional. Why not expose to PulseAudio the only two devices that are configured and functional? And to go one step further why not present the devices if they are connected to a receiver? -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ALSA sink enumeration and multiple devices/subdevices
> What I'm talking about is that pulseaudio is incapable of ever sending > audio to anything other than the default device/subdevice within a card, > irrespective of whether a cable is plugged in and signal being transmitted. ok, I am not sure I understand why there are several devices in the first place. Can you elaborate on what these 4 devices are? Can all these devices be used concurrently with different streams,ie up to 4 independent HDMI outputs/cables? Or is each device stereo only, and the hardware will multiplex channel pairs on the same HDMI link? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ALSA sink enumeration and multiple devices/subdevices
> If I hack /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf to > change hdmi-stereo's device-strings value to e.g. "hdmi:%f,0", "hdmi:%f,1", > etc., then I can cause pulseaudio to open whichever subdevice I wish. This > proves to me that this is simply an enumeration issue and nothing more > fundamental. I beg to disagree.. I have done similar work and I think there's something fundamentally broken in the ALSA/PulseAudio interaction for HDMI support(See my posts on the ALSA mailing list). On my Intel IbexPeak, there's only one HDMI device, but it is detected even though there's no cable connected. I can play audio on HDMI even if I unplug the cable. I would assume this is the same case for your Nvidia system, even if you hacked the profile definition, you would end-up with a set of detected profiles, but only one may work and only if there's a cable connected. That would beat any audio policy/device manager/intelligent routing logic. For HDMI, I think the right solution is to have some ALSA hot-plug event trapped by PulseAudio. Otherwise it's going to be really confusing for users. With Nvidia hardware, they would have to manually select which profile they want to play on, when they will want to play on the device that has a cable attached. Along the same lines, there's currently no means to know how many channels the receiver supports. We could add HDMI stereo/surround40/surround51/surround 71 profiles, but this is the least user-friendly solution. Again we do need some hot-plug event to set the relevant number of channels for the PulseAudio HDMI sink based on ELD/EDID information. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
>> Assuming your reasoning is correct (I'm not that deep into DMA yet), >> this should be fixed in the kernel - by not allowing rewinds further >> back than 128 (or 256) bytes ahead of actual position. >> You say HDA can transfer up to 128 bytes in advance, but what about all >> the other drivers? Could there be other drivers having a lot larger DMA >> fetches? > > What's the role of snd_pcm_rewindable()[1]? The documentation says "Get > safe count of frames which can be rewinded", which sounds to me like the > function should always be called before snd_pcm_rewind(). Currently PA > doesn't call _rewindable(). Yes it should be fixed in the kernel, but the DMA transfer size is not necessarily documented and known. Worse, it can vary depending on the mode. So until the kernel folks figure out a solution, and said solution works for all know drivers, this patch is mandatory on the PulseAudio side. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
>> * Pierre-Louis Bossart's version in git master sets a fixed margin of >> 256 bytes, (configurable if you load the sink manually, i e not through >> module-udev-detect). >> >> * My version sets a fixed margin of 20 ms. >> >> * My version only changes non-tsched devices and keeps tsched having a >> margin of the current watermark, whereas Bossart's version changes both. >> >> I think a margin should be based on milliseconds rather than bytes (the >> amount of bytes varies with amount of channels, which means that we >> might get problems when people switch to surround output). >> >> I don't have an opinion on whether a fixed margin or watermark-based >> margin is better for tsched sinks. >> > > > I presume Pierre-Louis will comment in due course. I'm sure he'll see > this message. > > I'm annoyed I didn't appreciate that his fix would likely address the > issue too when it was pushed, but such is life :D Well I didn't see the link between my patch (from April) and the problem David tried to fix either. Thanks Raymond for finding this out. Before making any conclusions, would the problem be solved with David's patch using the equivalent of 256 bytes, that is 1.45ms instead of 20ms? just want to make sure this is the same bug. Yes the safeguard is needed in both cases, timer scheduling or good ol' audio interrupts. This comes from limitations of the snd_pcm_rewind() routine, you can rewind the appl_ptr all the way to the hardware pointer, but you may have DMA transfers in flight that cannot be rewound. For example HDaudio can fetch up to 128bytes, I added a default a safeguard of 256bytes to be super safe, but in theory this should be adjusted depending on how the DMA operates. The DMA knows nothing about milliseconds, it behaves the same way no matter the sampling rate it, which is the reason why bytes make more sense, it's easier to correlate with the way the hardware works. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] gst pulsesrc and default caps
> It looks like it working for me. Or "resample method: (null)" mean some > thing other? > > > 1 source outputs(s) available. > index: 0 > driver: > flags: START_CORKED FIX_FORMAT FIX_RATE FIX_CHANNELS > state: RUNNING > source: 2 > > current latency: 0,00 ms > requested latency: 27,56 ms > sample spec: s16le 1ch 16000Hz > channel map: mono > Mono > resample method: (null) I tried on my set-up, and I have: source Output #1 Driver: protocol-native.c Owner Module: 9 Client: 4 Source: 1 Sample Specification: s16le 2ch 48000Hz Channel Map: front-left,front-right Which matches what I have in /usr/etc/pulse/daemon.conf and the following code in source-output.c if (data->flags & PA_SOURCE_OUTPUT_FIX_RATE) data->sample_spec.rate = data->source->sample_spec.rate; Basically when you use these flags, pulsesrc will get the same sample rate as your input, without any src in PulseAudio. But this may not be what you want, you may want a different rate than what your hardware provides. By using this flag you remove any flexibility. The rate should be defined with the pulsesrc caps, not with a hard-coded flag, some folks want an SRC in pulseaudio. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
