[mythtv] ALSA Sound Driver Question

[Paul Volkaerts]

> >I ran into a couple of other issues which I am still chasing but
> thought it
> >was worth putting my "findings so far" out there.
> >
> >1. Using the Alsa driver, a call to "getBufferOnSoundcard" returns zero
> >immediately after the first few calls to AddSamples. I think
> this is because
> >it only calls snd_pcm_delay if the state is running or draining, but the
> >state seems to stay as "PREPARED" for a while. I don't understand ALSA
> >enough to know what causes it to change from Prepared to
> Running, i.e. will
> >the first call to writei do this or does it need a minimum
> number of bytes?
> >
> >2. Because of the asynchronous nature of the drivers, there can
> be a gap of
> >around 5ms to 10ms between my first call to AddSamples and the data being
> >sent to the soundcard. (i.e. it has to wake from a sleep and
> then the task
> >has to be scheduled by the kernel). Can you think of any way of
> getting rid
> >of this?  Is it not possible to feed the soundcard from
> AddSamples directly
> >if the soundcard is empty?
> >
> >
>
> Is the issue to sync the record and playback streams?

My objective is to try and get the playback delay almost constant so I can
synchronise audio and video, which is (relatively!) easy for TV where you
can build a half-second buffer into playback but quite difficult if you want
to run the latency down to <100ms too.

But I think I sorted out the main problem (1 above) with ALSA -- I had not
adjusted the "period" so it was not actually starting playback until it had
1/4 sec of data. However I think it is still technically a bug in
"getBufferOnSoundcard" as it returns zero if the ALSA state is PREPARED. So
if 100ms of data has been sent to the driver but the driver is configured to
need 150ms of data before it starts, then it will return zero bytes queued.

My problem (2) is a minor niggle really. I setup the audio delay by writing
a period of silence (~40ms) to the audio driver, effectively using the audio
clock as a delay buffer, then I monitor this delay to ensure there is no
clock creep, discarding or inserting up to 1ms of speech per second to keep
on track. But the 40ms of silence I send at the start of a call can become
50ms because of the sleep() fn in audiooutput. It gets back to 40ms after 10
seconds of me throwing away 1ms of speech per second, which is almost
un-noticeable.  This would be a nice-to-have-fixed --- some way of calling
WriteAudio within AddSamples if the driver is idle. I'm not going to lose
sleep over it just yet though!


>
> I wonder if we shouldn't just move the record code into the audio driver
> and then we can use the various alsa features to ensure absolutely
> perfect record and playback sync?  This does mean adding a fairly
> serious bunch of code, but it needs to go somewhere I guess...
>
> I use Jack for my audio in and out, so I'm going to have to write record
> routines for this anyway.  Perhaps we should be designing the interface
> in order to just add this stuff into the audio classes?

Sync of record/playback is not that big an issue yet, until I add echo
cancellation.  I downloaded some code to do that and am going to have a shot
soon.  But the main problem here is that I use the microphone on my webcam,
so its on a different soundcard to my speaker.  So getting 100% sync is
going to be a challenge.