Alsa over HDMI goes async or gives crackling

[10robinho]

I've posted on forum about this bug: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=48769

After I talked to some gstreamer guys, it seams that this bug is related to alsa drives for Raspberry Pi.

Long story in short, changing "buffer-time" property of gstreamer alsasink makes sound late (if buffer-time is high) or makes crackling noise (if buffer-time is lower).

On other platforms, there is no need to change "buffer-time" property and there are no issues with gstreamer alsasink (this bug can be reproduced only with Raspberry).

Is there any chance someone can reproduce this, give an explanation or even fix?

[popcornmix]

The Pi has to send audio to the GPU, so and requires a larger buffer to avoid underrun than a processor that cam dma audio directly.

If the units for:
g_object_set(GST_OBJECT(alsasink), "buffer-time", 50000, NULL);
are microseconds, then it's quite possible that 50ms is the minimum buffer size that can be supported without risking underrun (and hence the crackles).

If this causes out of sync audio, then that sounds like a gstreamer bug, where it is not adjusting the audio/video delay by the audio buffer size.

[10robinho]

Yes, values are in microseconds. Default value is 200ms and there is no crackling when using it.

But, strange thing is that Raspberry is only platform that is having this desyncronisation with alsasink.

So, as far as I know now, several items are candidates for bug source: alsa drivers, alsa sink, egl sink or some internal Gstreamer.

I think that it is hardly possible that Gstreamer has internal problem as it is widely used and tested.

I'll try to see if I will get any feedback from people who are familiar with alsasink.

Anyways, it would be really pity that Gstreamer don't work properly on Raspberry.

[popcornmix]

I'm sure gstreamer has an option to specify the delay between video and audio.
You probably just need to set this to 200ms.

[10robinho]

That would be great if delay is really 200ms. But problem is that delay is 0ms on start (sync is working) and it is increasing proportional to number of play-pause events.

[popcornmix]

I don't think anything will be done about this without some evidence of where the problem is.
The crackles when buffer size is too low is expected behaviour.

Going out of sync could easily be a gstreamer problem.
If there is an alsa problem, you really need a small program that provokes the problem without gstreamer/egl etc.

[10robinho]

OK, I will report back when I debug Gstreamer more, to find out possible source of bug.

It would be great if anyone can try to compile samples I attached on bug report and to confirm this.

Here is bug report https://bugzilla.gnome.org/show_bug.cgi?id=703330

[10robinho]

I've found exactly the same problem with mplayer using alsa sink.

There are steps how to reproduce it easily:

1. Here is video I used http://goo.gl/W4p6v. Note that is super-small because I had to make sure Raspberry can properly reproduce it without any GPU help. But still, it is h264 + AAC in mp4 format. I used ffmpeg to reduce original Simpsons movie trailer that can be found here http://goo.gl/HXXvX.
   I find it good for testing audio because Homer slaps those wolfs in start and it is easy to see is audio is synced :)
2. Install mplayer :) I used Arch packages
3. Start X
4. Run: mplayer -va x11 -ao alsa video.mp4
5. Hit space couple of times until you realize that sound is late

It would be great if someone could confirm this bug.

[10robinho]

@popcornmix have you tried to reproduce this bug?

Is there anything I can do to help fixing this?

[julianscheel]

We're just stumbling into the same/similiar issue with our VLC implementation. Actually from our current understanding it looks as if snd_pcm_drop is not behaving correctly. Whenever VLC thinks that audio is way too late and tries to flush the audio output, the audio delay compared to video grows.
Analysing this we are currently thinking about the workqueue implementation of the snd_bcm2835 driver.
@popcornmix Could it be that the workqueue behaves as an in fact unlimited buffer, because snd_pcm_write calls are pushed to the workqueue asynchronously from actual tranfer to videocore? And then if a stop with snd_pcm_drop is executed this is just pushed onto the same workqueue, so it will only get executed after all previous write calls have been finished?
We are trying to find an easy test-case for this...

[dennis-hamester]

MPD is also affected by issues regarding snd_pcm_drop and they implemented a workaround. See this commit.

[10robinho]

Check
https://github.com/albertd/buildroot-rpi/commit/b56624dcd4237f9a67231dd225884e372d4917e3

[dennis-hamester]

Great, thanks! We will try that patch

[10robinho]

@dennishamester we tried to adopt that patch to Kernel from github.com/raspberrypi/ and we have found out that it works only for Kernel 3.9 and that it resets alsa settings after call (ei. that means sound jumps on 100% every time).

It would be nice to have fix for this, now when root of problem is known.

[popcornmix]

@julianscheel a simple test case of the problem would be very helpful.

Assuming the problem described is fixed by the kernel patch, it looks like a stop message with alsa_stream->draining==0 is the problem case. Agreed?

There is a queue of audio data on GPU side. Is the desired behaviour for that queue to be flushed when a stop message comes through with alsa_stream->draining==0 ?
I assume I report the samples have been played (just taking no time), so dma read_ptr==write_ptr after this?

[dennis-hamester]

@popcornmix yes, the problem appears when stop messages with draining==0 are generated. These come from snd_pcm_drop, which expects playback to stop immediately, with all pending buffers being discarded.