Re: [RDD] Fixing ALSA playback on weird cards
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 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 > > Date: Wed, Dec 25, 2013 at 2:11 AM > > Subject: Fixing ALSA playback on weird cards > > To: rivendell-p...@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?___ > > Rivendell-dev mailing list > > Rivendell-dev@lists.rivendellaudio.org > > http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev > ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Fixing ALSA playback on weird cards
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 > Date: Wed, Dec 25, 2013 at 2:11 AM > Subject: Fixing ALSA playback on weird cards > To: rivendell-p...@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?___ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
[RDD] Fixing ALSA playback on weird cards
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 Date: Wed, Dec 25, 2013 at 2:11 AM Subject: Fixing ALSA playback on weird cards To: rivendell-p...@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? ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
