Re: [pulseaudio-discuss] long delay after paplay -s somehost foo.wav
Hi, On Wed, Aug 10, 2011 at 09:47:47PM +0800, Paul Fox wrote: colin wrote: 'Twas brillig, and Paul Fox at 08/08/11 15:21 did gyre and gimble: ... but this: paplay -s server one.wav paplay -s server two.wav will result in a delay of over 2 seconds between one and two. ... This is likely related to the drain. In order to be 100% sure that the data is no longer needed (as it may be needed by rewind buffers) we have to wait. There are a few bug reports about this kind of thing in e.g. the simple protocol, but I'm not sure we can solve it 100% in all cases. thanks. i found this: http://www.pulseaudio.org/ticket/866 it certainly sounds like a fix will be a long time coming. it feels to me that there should be a way for a stream to be started with a different contract, i.e., i will never rewind this stream. please deliver the data on a best-effort basis. i don't require acknowledgement of the last byte. i.e., exactly the conditions needed by most real-world uses of pa_play. The 2s delay is likely related to the amount of audio that is buffered by default. i've modified the pacat-simple.c example to let me play with the pa_buffer_attr passed to pa_simple_new, but can't seem to find a combination that avoids the 2s wait. I did some experiment to set the tsched buffer size down a little bit and for me the wait time becomes smaller. This makes sense since the total buffer becomes smaller and the time to wait it to be drained is smaller. As this parameter is not exported via module-udev-detect, so you have to use this hack method instead: pacmd list-modules [find the module index of your alsa card] unload-module the-above-index-you-find load-module module-alsa-card device_id=0 name=pci-_00_1b.0 card_name=alsa_card.pci-_00_1b.0 namereg_fail=false tsched=yes ignore_dB=no sync_volume=yes card_properties=module-udev-detect.discovered=1 tsched_buffer_size=some-number [note the parameter here may differ from yours, but you can get it from list-modules above, see the arguments part] Change the tsched_buffer_size to some number smaller. How to decide the number? Before you unload this module, invoke list-sinks and check this property: device.buffering.buffer_size. You may need to try half the number again and again to see how it fixes your problem. The cons of this action is you gets poor power consumption, the wakeup gets more and if it's too small, more chances of underrun. Be cautious. It's more like a tuning thing. You can take a try. removing the call to pa_simple_drain(), however, and (hack alert!) substituting usleep(10) seems to do the trick, for me. i do get a click between played files, though, so i'm not done. paul Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 62.4 degrees) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] long delay after paplay -s somehost foo.wav
lu wrote: Hi, On Wed, Aug 10, 2011 at 09:47:47PM +0800, Paul Fox wrote: colin wrote: 'Twas brillig, and Paul Fox at 08/08/11 15:21 did gyre and gimble: ... but this: paplay -s server one.wav paplay -s server two.wav will result in a delay of over 2 seconds between one and two. ... This is likely related to the drain. In order to be 100% sure that the data is no longer needed (as it may be needed by rewind buffers) we have to wait. There are a few bug reports about this kind of thing in e.g. the simple protocol, but I'm not sure we can solve it 100% in all cases. thanks. i found this: http://www.pulseaudio.org/ticket/866 it certainly sounds like a fix will be a long time coming. it feels to me that there should be a way for a stream to be started with a different contract, i.e., i will never rewind this stream. please deliver the data on a best-effort basis. i don't require acknowledgement of the last byte. i.e., exactly the conditions needed by most real-world uses of pa_play. The 2s delay is likely related to the amount of audio that is buffered by default. i've modified the pacat-simple.c example to let me play with the pa_buffer_attr passed to pa_simple_new, but can't seem to find a combination that avoids the 2s wait. I did some experiment to set the tsched buffer size down a little bit and for me the wait time becomes smaller. This makes sense since the total buffer becomes smaller and the time to wait it to be drained is smaller. As this parameter is not exported via module-udev-detect, so you have to use this hack method instead: thanks! will doing this result in different behavior than modifying the pa_buffer_attr struct that's passed to pa_simple_new()? (other than it affecting all clients, instead of just one, that is.) paul pacmd list-modules [find the module index of your alsa card] unload-module the-above-index-you-find load-module module-alsa-card device_id=0 name=pci-_00_1b.0 card_name=alsa_card.pci-_00_1b.0 namereg_fail=false tsched=yes ignore_dB=no sync_volume=yes card_properties=module-udev-detect.discovered=1 tsched_buffer_size=some-number [note the parameter here may differ from yours, but you can get it from list-modules above, see the arguments part] Change the tsched_buffer_size to some number smaller. How to decide the number? Before you unload this module, invoke list-sinks and check this property: device.buffering.buffer_size. You may need to try half the number again and again to see how it fixes your problem. The cons of this action is you gets poor power consumption, the wakeup gets more and if it's too small, more chances of underrun. Be cautious. It's more like a tuning thing. You can take a try. removing the call to pa_simple_drain(), however, and (hack alert!) substituting usleep(10) seems to do the trick, for me. i do get a click between played files, though, so i'm not done. paul Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 62.4 degrees) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- guanqun =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 67.8 degrees) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] long delay after paplay -s somehost foo.wav
The 2s delay is likely related to the amount of audio that is buffered by default. i've modified the pacat-simple.c example to let me play with the pa_buffer_attr passed to pa_simple_new, but can't seem to find a combination that avoids the 2s wait. Have you played with the prebuf field? It defines the amount of buffering before playback starts. By default it is set to the tlength size, that may explain your 2s wait. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] long delay after paplay -s somehost foo.wav
pierre-louis wrote: The 2s delay is likely related to the amount of audio that is buffered by default. i've modified the pacat-simple.c example to let me play with the pa_buffer_attr passed to pa_simple_new, but can't seem to find a combination that avoids the 2s wait. Have you played with the prebuf field? It defines the amount of buffering before playback starts. By default it is set to the tlength size, that may explain your 2s wait. i don't think so. the 2s happens at the end of playback, not the start. the trac ticket i referenced explains it pretty well. (but to answer your question, yes, i played with it.) paul =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 69.4 degrees) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] long delay after paplay -s somehost foo.wav
Have you played with the prebuf field? It defines the amount of buffering before playback starts. By default it is set to the tlength size, that may explain your 2s wait. i don't think so. the 2s happens at the end of playback, not the start. the trac ticket i referenced explains it pretty well. (but to answer your question, yes, i played with it.) Quite frankly I am not sure what the problem is, even after reading the bug description. In your test file, you have a single stream open. If you write sequentially multiple tones, they will be played one after the other. There cannot be any issues with synchronization here, things are serial by construction. And if you want your program to exit quickly, then you should use pa_simple_flush, otherwise you will always have to wait for the buffered data to be played out. Indeed pa_simple_drain has a delay, but I fail to see how it's a blocking point. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] long delay after paplay -s somehost foo.wav
pierre-louis wrote: Have you played with the prebuf field? It defines the amount of buffering before playback starts. By default it is set to the tlength size, that may explain your 2s wait. i don't think so. the 2s happens at the end of playback, not the start. the trac ticket i referenced explains it pretty well. (but to answer your question, yes, i played with it.) Quite frankly I am not sure what the problem is, even after reading the bug description. In your test file, you have a single stream open. If you write sequentially multiple tones, they will be played one after the other. There cannot be any issues with synchronization here, things are serial by construction. And if you want your program to exit quickly, then you should use pa_simple_flush, otherwise you will always have to wait for the buffered data to be played out. Indeed pa_simple_drain has a delay, but I fail to see how it's a blocking point. pa_play -s somehost tone1.wav pa_play -s somehost tone2.wav pa_play -s somehost tone3.wav the three tones will be separated by 2.2 second gaps of silence. paul =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 72.1 degrees) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] long delay after paplay -s somehost foo.wav
'Twas brillig, and Paul Fox at 08/08/11 15:21 did gyre and gimble: i have a long-standing problem with commandline access to pulseaudio across the network. i have a scripted application that needs to be able to play multiple sound files back to back, with as little silence between them as possible. (the soundbites are spoken phrases, so a tiny gap is acceptable.) but this: paplay -s server one.wav paplay -s server two.wav will result in a delay of over 2 seconds between one and two. examining the operation of paplay and the remote pulseaudio server with strace tells me that the delay is occuring at the end of the first command (as opposed to the beginning of the second). the delay is a 2.2 second wait at the end of paplay for some sort of final acknowledgement from the server. on the server side, it seems that this delay is spent waiting from data from the audio driver? (just guessing about this, since i'm just looking at strace, and the fd being polled isn't a file node, but appears in /proc/pid/fd as anon_inode:[eventfd].) in any case, since this may be a well-known problem (or feature, even :-), i figure i should ask about it before going further. i should add that on another incarnation of this application setup, i've used nasd and auplay to transfer the audio, and the files play almost seamlessly. my setup: i'm running 0.9.21-63-gd3efa-dirty on ubuntu 10.10 on both clients and server. the protocol is enabled with: load-module module-native-protocol-tcp auth-anonymous=1 and the server is running in system mode (because the audio needs to work when no one is logged in). thanks in advance for any suggestions. This is likely related to the drain. In order to be 100% sure that the data is no longer needed (as it may be needed by rewind buffers) we have to wait. There are a few bug reports about this kind of thing in e.g. the simple protocol, but I'm not sure we can solve it 100% in all cases. The 2s delay is likely related to the amount of audio that is buffered by default. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
