Re: [pulseaudio-discuss] [PATCH] stream: Return error in case a client peeks to early
On 10/02/2012 10:38 PM, Tanu Kaskinen wrote: On Mon, 2012-10-01 at 17:06 +0200, David Henningsson wrote: If there is no silence memblock and no data, pa_memblockq_peek can return NULL. In this case, do not crash on an assertion in pa_memblock_acquire, but instead return a proper error to the client. If there is no data in the buffer, pa_stream_peek() is supposed to return NULL according to the documentation. And it does that: if there's no data, pa_memblock_peek() will return a negative value, causing pa_stream_peek() to return NULL. The problem is the case where the buffer does contain data, but not at the read index. That is, there is a hole in the buffer. The client documentation doesn't have any warnings about holes, so the only safe way to handle holes is to return silence. Fixing this should be a simple matter of giving a silence memchunk when creating record_memblockq. I'm not so sure. Silence, as in all zeroes, might work for S16 audio data, but what about other formats? Compressed audio? Peak audio (which I think is the case here)? Etc. Also maybe it could also be valuable for the client to distinguish between no data available, and valid zero data. How about returning NULL and adding to the documentation something like: -If no data is available this will return a NULL pointer. +If no data is available (at the current read position), this will return a NULL pointer. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio lag at sound end
(Adding the mailing list back to recipients.) On Tue, 2012-10-02 at 23:23 +0200, Samuele Carcagno wrote: > > > > First of all, this is a known issue: http://pulseaudio.org/ticket/866 . > > It's a bit tricky to fix, and so far nobody has volunteered to work on > > it. > > > > I think it should be a viable workaround to keep the latency of the sink > > low while you play your files. There's no direct knob that you can use > > to control the latency, but you can play something, and request that to > > be played with low latency. The sink latency will be configured > > accordingly. If you use paplay instead of aplay, you can request a > > latency: paplay --latency-msec=50 somefile.wav. I would expect that to > > help, but if not, you could also try keep the latency low all the time > > by playing silence in the background: pacat --latency-msec=50 /dev/zero > > > > > > many thanks for the info, I've tried your workarounds but the latency still > remains > very large. Hope this issue will be fixed in some future release. Was there no improvement? I'm surprised. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ARM NEON patches, status
On Mon, 2012-10-01 at 11:15 +0200, Peter Meerwald wrote: > Hello, > > > I have submitted v3 of my ARM NEON patches July 24 > > (http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-July/014226.html) > > but not received any feedback > > any comment on this? Sorry for the lack of feedback. Arun, do you have time to check these patches? If not, I'll do that, but I imagine that you know this stuff better than me... -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v4] alsa-mixer: Cache failure to open inputs/output mappings
On Mon, 2012-10-01 at 15:37 +0200, David Henningsson wrote: > I was hoping this would improve bootup speed, but it doesn't seem > to do so here, at least not much. But at least it reduces the logs > a little. > > Signed-off-by: David Henningsson Thanks! Applied now. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC PATCH] alsa-mixer: Cache failure to open inputs
On Mon, 2012-10-01 at 15:48 +0200, David Henningsson wrote:
> On 09/25/2012 06:46 PM, Tanu Kaskinen wrote:
> > On Mon, 2012-09-24 at 17:02 +0200, David Henningsson wrote:
> >> On 09/24/2012 03:33 PM, Tanu Kaskinen wrote:
> >>> Ok, I don't have a problem with this example. But the code in your patch
> >>> has different structure: instead of a simple match_found() call, the
> >>> inner code contains a three-line block.
> >>
> >> Well, I still think
> >>
> >> for (i)
> >> for (j)
> >> if (a[i] == b[j]) {
> >> three();
> >> line();
> >> block();
> >> }
> >>
> >> ...looks better than
> >>
> >> for (i)
> >> for (j)
> >> if (a[i] == b[j]) {
> >> three();
> >> line();
> >> block();
> >> }
> >> }
> >> }
> >>
> >> ...but maybe that's just me.
> >
> > I certainly prefer the latter, though this is not a very important thing
> > for me. But I'm now left wondering what you thought we agreed earlier -
> > unfortunately I don't have the logs, but I think we agreed to disallow
> > some cases of omitting the braces. If you think that the first example
> > would still be allowed, I don't know what case would be left to
> > disallow.
>
> I don't recall for sure, but I think I was imagining multiline
> statements, e g
>
> if (i)
> this_is_a_very_long_statement(with_multiple, parameters,
> that_maybe_are_functions(themselves));
>
> vs
>
> if (i) {
> this_is_a_very_long_statement(with_multiple, parameters,
> that_maybe_are_functions(themselves));
> }
>
> in which case the latter is okay. Anyway, if it's not important, it's
> just another trap to fall in when you try to fix somebody's real problem.
Ok, thanks for clarifying that. Since it was unclear what we decided,
effectively we didn't decide anything. Therefore, until we decide
something else, I think the policy stays as it has been. So, this will
cause complaints:
if (a) {
foo();
}
and anything more complicated is unregulated (i.e. no complaints, braces
or not).
> >> I don't know if we have a generic opinion on whether we prefer NULL
> >> idxsets or empty idxsets? Or determine on a case-by-case basis?
> >
> > I don't think there has been any rule so far, or if there has been, it
> > has been to favor NULL. I would definitely choose to always initialize
> > idxsets and hashmaps if there's no particular reason to distinguish
> > between NULL and an empty container. (I have even sent some patches that
> > ensure that certain idxsets or hashmaps are always non-NULL, but I don't
> > remember if they have been reviewed yet.) It makes the code simpler when
> > you don't have to worry about the container being NULL.
>
> Another option could be to make pa_hashmap_* to treat NULL pointers as
> empty containers. I don't know if that's better though.
I think the assertions on NULL pointers given to pa_hashmap_* have
value, so I'm opposed to that proposal. I don't see any significant
problems with always initializing the containers, do you? The increased
memory use should be negligible.
--
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio lag at sound end
On Tue, 2012-10-02 at 22:16 +0200, Samuele Carcagno wrote: > Hi, > > I have the same issue that is described in this post (not mine) > > http://unix.stackexchange.com/questions/7067/do-the-play-utility-in-linux-really-have-a-delay-to-stop-its-process-with-r > > basically, when I play a sound with aplay or other command line > utilities, when the sound ends there is a long delay (about 3 seconds) > before the program returns. This is an issue for me because I play two > or more sounds in sequence from a python program for > psychoacoustics research, and the silent interval between two sounds > needs to be roughly controlled. I could make wav files > with the sounds in sequence and silence between them, but the sounds > need to be synchronized with lights, and this is not > so easy to achieve with a single long wav file. > > I was wondering whether there are any settings in pulseaudio that can > be tweaked to reduce this sound offset lag to negligible levels. > I should add that with alsa (that is when I remove pulseaudio from my > system) there is not such problem, aplay starts and returns > without noticeable delays. For this reason I have been living without > pulseaudio so far, but some programs start not running well > without it (skype on Kubuntu Precise), so it would be great if I could > solve the issue. > > Thanks for any help! First of all, this is a known issue: http://pulseaudio.org/ticket/866 . It's a bit tricky to fix, and so far nobody has volunteered to work on it. I think it should be a viable workaround to keep the latency of the sink low while you play your files. There's no direct knob that you can use to control the latency, but you can play something, and request that to be played with low latency. The sink latency will be configured accordingly. If you use paplay instead of aplay, you can request a latency: paplay --latency-msec=50 somefile.wav. I would expect that to help, but if not, you could also try keep the latency low all the time by playing silence in the background: pacat --latency-msec=50 /dev/zero -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] stream: Return error in case a client peeks to early
On Mon, 2012-10-01 at 17:06 +0200, David Henningsson wrote: > If there is no silence memblock and no data, pa_memblockq_peek can > return NULL. In this case, do not crash on an assertion in > pa_memblock_acquire, but instead return a proper error to the client. If there is no data in the buffer, pa_stream_peek() is supposed to return NULL according to the documentation. And it does that: if there's no data, pa_memblock_peek() will return a negative value, causing pa_stream_peek() to return NULL. The problem is the case where the buffer does contain data, but not at the read index. That is, there is a hole in the buffer. The client documentation doesn't have any warnings about holes, so the only safe way to handle holes is to return silence. Fixing this should be a simple matter of giving a silence memchunk when creating record_memblockq. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] pulseaudio lag at sound end
Hi, I have the same issue that is described in this post (not mine) http://unix.stackexchange.com/questions/7067/do-the-play-utility-in-linux-really-have-a-delay-to-stop-its-process-with-r basically, when I play a sound with aplay or other command line utilities, when the sound ends there is a long delay (about 3 seconds) before the program returns. This is an issue for me because I play two or more sounds in sequence from a python program for psychoacoustics research, and the silent interval between two sounds needs to be roughly controlled. I could make wav files with the sounds in sequence and silence between them, but the sounds need to be synchronized with lights, and this is not so easy to achieve with a single long wav file. I was wondering whether there are any settings in pulseaudio that can be tweaked to reduce this sound offset lag to negligible levels. I should add that with alsa (that is when I remove pulseaudio from my system) there is not such problem, aplay starts and returns without noticeable delays. For this reason I have been living without pulseaudio so far, but some programs start not running well without it (skype on Kubuntu Precise), so it would be great if I could solve the issue. Thanks for any help! Sam ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
