[RDD] Fixing ALSA playback on weird cards

Karl Koscher supersat at uwave.fm
Tue Jan 7 03:57:25 EST 2014


It's an M-Audio FastTrack Pro, which has been known to be a bit wonky under
Linux. I'm just doing some experiments until we can get proper audio
interfaces. Using another interface might work, but that code seems broken
to me, so it should probably be fixed.


On Mon, Jan 6, 2014 at 7:02 AM, Lorne Tyndale <ltyndale at tyndaleweb.com>wrote:

> Hi,
>
> Just out of interest, what sound card is causing this difficulty?  Any
> chance you could try a different sound card?
>
> Also, one thing I've found is that for some cards I have to specify the
> rate in asound.conf for them to work properly (particularly intel
> chipset based cards).  Putting a rate 44100 or rate 48000 in asound.conf
> generally fixes playback issues that I've run into.
>
>
>
>
>
>
> >
> >
> > I sent this earlier to rivendell-prog but never got a reply. Perhaps it
> was
> > the holidays, or maybe that mailing list is deprecated?
> >
> > ---------- Forwarded message ----------
> > From: Karl Koscher <supersat at uwave.fm>
> > Date: Wed, Dec 25, 2013 at 2:11 AM
> > Subject: Fixing ALSA playback on weird cards
> > To: rivendell-prog at lists.rivendellaudio.org
> >
> >
> > For whatever reason, one of our ALSA playback cards reports a sampling
> rate
> > of 44099 instead of the usual 44100. Any playback on this device quickly
> > gets distorted, and though some debugging, I found that a byte was being
> > dropped. The culprit is the code in FillAlsaOutputStream that adjusts the
> > amount of data it reads in if the card's playback rate is not the same as
> > the stream's. The amount of data to read is divided by the ratio between
> > the card's playback rate and the stream's rate. If the playback
> ringbuffer
> > is empty, this increases the amount of data to read beyond the capacity
> of
> > the ringbuffer. In that case, the ringbuffer code takes the first 2^18-1
> > bytes, which causes the samples to become misaligned.
> >
> > I'm trying to figure out the purpose of this code. FillAlsaOutputStream
> > will always fill the ringbuffer, so the rate that it's filled doesn't
> need
> > to be adjusted. It could also be to do a form of poor resampling by
> > dropping samples periodically, but this only works if the playback rate
> is
> > lower than the stream's sample rate, and it doesn't do this resampling
> when
> > the ringbuffer is initially filled. Is there a reason for this code, or
> can
> > it be pulled out?<hr>_______________________________________________
> > Rivendell-dev mailing list
> > Rivendell-dev at lists.rivendellaudio.org
> > http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://caspian.paravelsystems.com/pipermail/rivendell-dev/attachments/20140107/56996952/attachment-0001.html>


More information about the Rivendell-dev mailing list