Re: Still have choppy audio using 1.0.17

[Gustavo da Silva Serra <gustavo.serra@tet.com.br>]

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
>>> guaranteed.
>>>
>>>
>>> Just my $0.02.
>>>
>>> Takashi
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>       
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
> __________ NOD32 3241 (20080704) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
>
>