[alsa-devel] Still have choppy audio using 1.0.17
Gustavo da Silva Serra
gustavo.serra at tet.com.br
Mon Jul 14 19:57:13 CEST 2008
I have discovered something else. Choppy audio occurs when
snd_pcm_playback_silence, in pcm_lib.c, will silence the same period
than the capture pointer is pointing at. I am printing this variables
"ofs" in snd_pcm_playback_silence and what is returned from
snd_card_loopback_pointer when the substream is capture.
How snd_pcm_playback_silence is supposed to work? Must it silence the
next period from the playback pointer? How is ensured that this
situation (ofs == capture pointer) does not happen with sound cards?
Thanks ANY help... any...
Gustavo da Silva Serra escreveu:
> I forgot a very important detail, when I can choose the output plugin
> (alsa or oss in Kaffeine, for example), only alsa has choppy audio. oss
> plugin works perfectly, only using kernel module emulation.
> Gustavo da Silva Serra escreveu:
>> I have tried to implement the solution you proposed. However I still
>> get choppy audio, just like before, otherwise the sound is clear.
>> Basically I moved the timer to the cable struct, and updated the timer
>> function to update both playback and capture.
>> I am sending the code attached so you can see if I implemented what
>> you suggested. The code is not very clean, nor completely functional,
>> as I never programmed to kernel before, and might cause kernel panic
>> when closing a stream.
>> Any other suggestions?
>> Thanks for the help and the attention.
>> Takashi Iwai escreveu:
>>> At Wed, 25 Jun 2008 08:24:33 -0300,
>>> Gustavo da Silva Serra wrote:
>>>> If I keep the difference between the playback and capture pointers
>>>> at one period, no choppy audio occurs. If the difference is 0, 2 or
>>>> 5 periods for example, choppy audio will always occur. Any ideas why?
>>> Through a quick look at the code, it's likely the problem of the
>>> timing of timer handlers for playback/capture streams. In the current
>>> code, the timer handlers are invoked individually.
>>> One possible fix would be to force to synchronize the updates of both
>>> directions instead of individual timers. That is, share the same
>>> timer for the connected streams so that the update order is
>>> Just my $0.02.
>>> Alsa-devel mailing list
>>> Alsa-devel at alsa-project.org
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> __________ NOD32 3241 (20080704) Information __________
> This message was checked by NOD32 antivirus system.
More information about the Alsa-devel