Re: [Alsa-devel] should i be able to abort in the middle ofsnd_pcm_mmap_{begin,commit} ?
On Wed, 13 Feb 2002, Paul Davis wrote: [xrun after mmap_begin] after restarting, the audio stream is not in sync - it contains minor crackles and clicks suggesting that the device driver doesn't really know where the hw pointer is. the effect varies with the period size, which reinforces my belief in what's gone wrong. this happens on both the hammerfall and the trident, though the effect sounds a little I've noticed similar problems with CVS versions of ALSA and JACK. My card is ens1371. The crackled audio doesn't occur every time, but practically always after a subgraph timeouts. The sound is mostly ok (stereo image is fine, rate is correct, also amplitude), but it's badly garbled (for lack of a better adjective). Hmm, it could be that committed periods overlap in hw mem, or are shorter than longer than what hw excepts (- gaps between committed periods). -- http://www.eca.cx Audio software for Linux! ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] should i be able to abort in the middle ofsnd_pcm_mmap_{begin,commit} ?
On Wed, 13 Feb 2002, Paul Davis wrote:
should it work for me to call snd_pcm_drop() for both playback and
capture streams if i'm in the middle of a snd_pcm_mmap_{begin,commit}
pair?
Nope. Do you think that we need to lock these related code blocks in
alsa-lib for threaded applications or leave this locking for application
coders?
unless i use RT timing, on both the trident and hammerfall, doing do
invariably causes an effect upon restarting the streams that suggests
an out-of-sync hw-pointer.
I don't wonder.
Jaroslav
-
Jaroslav Kysela [EMAIL PROTECTED]
SuSE Linuxhttp://www.suse.com
ALSA Project http://www.alsa-project.org
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] should i be able to abort in the middle ofsnd_pcm_mmap_{begin,commit} ?
On Wed, 13 Feb 2002, Paul Davis wrote:
should it work for me to call snd_pcm_drop() for both playback and
capture streams if i'm in the middle of a snd_pcm_mmap_{begin,commit}
pair?
Nope. Do you think that we need to lock these related code blocks in
alsa-lib for threaded applications or leave this locking for application
coders?
leave it for applications.
but here's the problem. i'm in the middle of an mmap_{begin,commit}
pair, and i realize that i've caused a xrun (e.g. because i waited too
long via poll(2) for something else to happen). there's no point
calling mmap_commit() at this point, since i know i don't have any
data to commit and i know i'm too late. what i want to do is to stop
the interface, and then restart it from scratch. so, i am effectively
doing:
poll
snd_pcm_mmap_begin();
snd_pcm_mmap_commit();
poll
snd_pcm_mmap_begin();
... realize things have gone wrong ...
snd_pcm_drop();
snd_pcm_prepare();
snd_pcm_start ();
poll
snd_pcm_mmap_begin();
snd_pcm_mmap_commit();
i would have expected snd_pcm_drop() to effectively shut down the
driver, or at least for snd_pcm_drop() and snd_pcm_prepare() to get it
back to a pristine state again.
so, how should i handle such a condition?
The described sequence should work. As Abramo stated, the new
snd_pcm_mmap_begin() call is enough. What exactly fails?
Jaroslav
-
Jaroslav Kysela [EMAIL PROTECTED]
SuSE Linuxhttp://www.suse.com
ALSA Project http://www.alsa-project.org
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
