should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Paul Davis]

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?

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.

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Jaroslav Kysela]

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 <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA Project  http://www.alsa-project.org


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Paul Davis]

>> 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?

--p


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Jaroslav Kysela]

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 <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA Project  http://www.alsa-project.org



_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Paul Davis]

>>     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. 

that implies that the h/w is left running between the failure point
and the snd_pcm_mmap_begin() call, right? that would be bad - the
playback stream will contain data, and we will continue to hear it
will we clean up. the driver is set to *not* handle xruns by itself.


>				      What exactly fails?

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
different on each one.

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Kai Vehmanen]

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
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Kai Vehmanen]

>From alsa-devel... 

I've now added a few debugging points to jackd's alsa_driver.c:
	- five checks for xruns in various parts
	  of alsa_driver_wait() (prints an error if xrun
	  is detected; check with snd_pcm_state())
	- prints an error if playback_avail or capture_avail
	  is not 1024 (period size in use)
	- prints a warning everytime alsa_driver_wait()
	  takes more than 25msecs (23.2msec == period time)

In the below test run, audio got garbled when the ecasound
subgraph timed out. To create the timeout I generated lot of cpu and disk 
i/o stress. Few points to note:

- no xruns are detected even though after the timeout
  alsa_driver_wait() took 56.4msec which is more than
  period_size * number_of_periods (1024*2/44100*1000=46msec);
  in other words there should have been an xrun
- after the subgraph timeout I stopped all other heavy 
  processes; for some reason executing 
  alsa_driver_wait() still takes over 25msecs 
  every now and then (-> something happens slower than
  before subgraph timeout)

--cut--
./jackd -r 44100 -p 1024 -d hw:0 -v
jackd 0.11.0
Copyright 2001-2002 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

creating alsa driver ... hw:0|1024|2|44100|swmon
new client: alsa_pcm, type 1 @ 0x8061be0
registered port alsa_pcm:in_1
registered port alsa_pcm:in_2
registered port alsa_pcm:out_1
registered port alsa_pcm:out_2
ALSA: ports registered, starting driver
engine cycle took 26665.111588 usecs
new client: ecasound, type 2 @ 0x4017e000
registered port ecasound:defoutput_1
registered port ecasound:defoutput_2
connect ecasound:defoutput_1 and alsa_pcm:out_1
connect ecasound:defoutput_2 and alsa_pcm:out_2
engine cycle took 25305.427039 usecs
engine cycle took 32327.246781 usecs
engine cycle took 31287.197425 usecs
engine cycle took 26726.896996 usecs
engine cycle took 25433.017167 usecs
engine cycle took 25630.954936 usecs
engine cycle took 25678.708155 usecs
engine cycle took 29338.167382 usecs
engine cycle took 25405.414163 usecs
engine cycle took 31867.433476 usecs
engine cycle took 26505.763948 usecs
engine cycle took 25985.703863 usecs
engine cycle took 25095.143777 usecs
engine cycle took 25036.152361 usecs
engine cycle took 27495.572961 usecs
engine cycle took 28867.422747 usecs
subgraph starting at ecasound timed out (state = 2)
client ecasound state = 2
removing failed client ecasound
removing client ecasound
DIS-connect ecasound:defoutput_2 and alsa_pcm:out_2
DIS-connect ecasound:defoutput_1 and alsa_pcm:out_1
client alsa_pcm state = 0
engine cycle took 56401.128755 usecs
i/o error on unknown client fd 31
new client: ecasound, type 2 @ 0x4017e000
registered port ecasound:defoutput_1
registered port ecasound:defoutput_2
engine cycle took 40472.100858 usecs
connect ecasound:defoutput_1 and alsa_pcm:out_1
connect ecasound:defoutput_2 and alsa_pcm:out_2
engine cycle took 36322.628755 usecs
engine cycle took 30340.630901 usecs
engine cycle took 27335.261803 usecs
engine cycle took 25912.163090 usecs
engine cycle took 32502.793991 usecs
engine cycle took 27490.444206 usecs
engine cycle took 25834.858369 usecs
engine cycle took 25207.817597 usecs
engine cycle took 26574.560086 usecs
engine cycle took 29626.800429 usecs
engine cycle took 29376.212446 usecs
engine cycle took 27592.478541 usecs
engine cycle took 25239.598712 usecs
engine cycle took 26443.122318 usecs
engine cycle took 25291.517167 usecs
engine cycle took 25615.218884 usecs
engine cycle took 27318.682403 usecs
engine cycle took 44521.978541 usecs
engine cycle took 25640.030043 usecs
engine cycle took 25367.130901 usecs
engine cycle took 26560.156652 usecs
alsa_pcm: xrun of 2160 frames, (48.980 msecs)
engine cycle took 28737.905579 usecs
engine cycle took 25025.935622 usecs
engine cycle took 35878.388412 usecs
engine cycle took 39361.665236 usecs
engine cycle took 25087.163090 usecs
engine cycle took 29457.489270 usecs
engine cycle took 38277.605150 usecs
engine cycle took 25026.238197 usecs
engine cycle took 25052.620172 usecs
engine cycle took 25057.508584 usecs
engine cycle took 25170.804721 usecs
engine cycle took 25704.386266 usecs
DIS-connect ecasound:defoutput_1 and alsa_pcm:out_1
DIS-connect ecasound:defoutput_2 and alsa_pcm:out_2
removing client ecasound
engine cycle took 28678.154506 usecs
--cut--

On Thu, 14 Feb 2002, Kai Vehmanen wrote:

> 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
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Jackit-devel] Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Paul Davis]

>I've now added a few debugging points to jackd's alsa_driver.c:
>	- five checks for xruns in various parts
>	  of alsa_driver_wait() (prints an error if xrun
>	  is detected; check with snd_pcm_state())
>	- prints an error if playback_avail or capture_avail
>	  is not 1024 (period size in use)
>	- prints a warning everytime alsa_driver_wait()
>	  takes more than 25msecs (23.2msec == period time)
>
>In the below test run, audio got garbled when the ecasound
>subgraph timed out. To create the timeout I generated lot of cpu and disk 
>i/o stress. Few points to note:
>
>- no xruns are detected even though after the timeout
>  alsa_driver_wait() took 56.4msec which is more than
>  period_size * number_of_periods (1024*2/44100*1000=46msec);
>  in other words there should have been an xrun

i recall abramo saying that if the xrun happens within an
mmap_begin/commit pair, the driver can't detect it, or something like
that. 

i added kernel debugging to the hammerfall driver to check on aspects
of this problem. it demonstrated that everything at the driver level
was as expected. because this problem occurs on several different
cards, i am starting to suspect part of jack's design rather than
ALSA, but i have not yet managed to figure out what it could be. when
i check the channel_area_t addresses used by jack, they also appear to
be just as one would expect.

btw, ctrl-c'ing jack_simple_client will cause a timeout 80% of the
time on my machine, which is a simple, load-free way to create the problem.

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Jackit-devel] Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Kai Vehmanen]

On Thu, 14 Feb 2002, Paul Davis wrote:

>>- no xruns are detected even though after the timeout
>>  alsa_driver_wait() took 56.4msec which is more than
> cards, i am starting to suspect part of jack's design rather than
> ALSA, but i have not yet managed to figure out what it could be. when
> i check the channel_area_t addresses used by jack, they also appear to
> be just as one would expect.

It seems that the problem is:

- engine->process() is possibly a slow operation
- ALSA is unable to detect xruns inside mmap_begin()->mmap_commit()
  code block
-> engine->process() should not be inside the 
   begin()->commit() block

But the problem is that, as I understand it, mmap_begin() and
mmap_commit() are used to notify when application starts and stops
accessing a memory-mapped area. And engine->process() needs to do just
that, access the memory areas. This is the whole point of direct access.

So what we need is:

1. added layer of copying (I'd be suprised if anyone accepted 
   this one :)) so we can commit() the capture regions before
   entering engine->process()
2.a) way to notice that an xrun has happened during b->c 
  b) ability to reset the streams
3. way to make sure that engine->process() never takes longer
   than period_time*number_of_periods

Any ideas? I'd imagine this a problem all applications using the ALSA pcm
mmap API have to solve somehow (ecasound uses the read/write API so this
is all new to me).

-- 
 http://www.eca.cx
 Audio software for Linux!


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: [Jackit-devel] Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Jaroslav Kysela]

On Thu, 14 Feb 2002, Kai Vehmanen wrote:

> On Thu, 14 Feb 2002, Paul Davis wrote:
>
> >>- no xruns are detected even though after the timeout
> >>  alsa_driver_wait() took 56.4msec which is more than
> > cards, i am starting to suspect part of jack's design rather than
> > ALSA, but i have not yet managed to figure out what it could be. when
> > i check the channel_area_t addresses used by jack, they also appear to
> > be just as one would expect.
>
> It seems that the problem is:
>
> - engine->process() is possibly a slow operation
> - ALSA is unable to detect xruns inside mmap_begin()->mmap_commit()
>   code block

I wonder why you say this. There is really very short time period in which
the hardware pointer can cross the application pointer and PCM code won't
react on this situation. There are no locks for the xrun detection between
mmap_begin() and mmap_commit().

If you want to debug the real problem, try to print hw_ptr and appl_ptr
pointers when sound is garbled.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: [Jackit-devel] Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Kai Vehmanen]

On Thu, 14 Feb 2002, Jaroslav Kysela wrote:

>> - ALSA is unable to detect xruns inside mmap_begin()->mmap_commit()
>>   code block
> I wonder why you say this. There is really very short time period in which
> the hardware pointer can cross the application pointer and PCM code won't
> react on this situation. There are no locks for the xrun detection between
> mmap_begin() and mmap_commit().

Quoting Paul: "i recall abramo saying that if the xrun happens within an
mmap_begin/commit pair, the driver can't detect it, or something like
that." 

Anyways, in this case the hw pointer does reach the sw pointer and we
won't notice it (snd_pcm_state() reports SND_PCM_STATE_RUNNING).

> If you want to debug the real problem, try to print hw_ptr and appl_ptr
> pointers when sound is garbled.

I'll try that next.

-- 
 http://www.eca.cx
 Audio software for Linux!


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: [Jackit-devel] Re: should i be able to abortin the middle of snd_pcm_mmap_{begin,commit} ?

[Abramo Bagnara]

Kai Vehmanen wrote:
> 
> On Thu, 14 Feb 2002, Jaroslav Kysela wrote:
> 
> >> - ALSA is unable to detect xruns inside mmap_begin()->mmap_commit()
> >>   code block
> > I wonder why you say this. There is really very short time period in which
> > the hardware pointer can cross the application pointer and PCM code won't
> > react on this situation. There are no locks for the xrun detection between
> > mmap_begin() and mmap_commit().
> 
> Quoting Paul: "i recall abramo saying that if the xrun happens within an
> mmap_begin/commit pair, the driver can't detect it, or something like
> that."

Caution here... Paul is not very accurate quoting me, I'll try to
rephrase.

Take as an example HW PCM case, snd_pcm_mmap_begin and commit don't
enter kernel space and don't check for anything.

Note also that it's very hard to know if an xrun is actually happened or
not. We might use a conservative approach (i.e. all frames are
considered written on buffer only at commit call) a less severe one
(i.e. all frames are considered written at begin call), or a mixed
approach.

Current assumption is that between snd_pcm_avail_update call and
snd_pcm_mmap_commit we always put more data than hardware can read
(playback case)

Of course preemption can give us surpries, but that's life...

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Jackit-devel] Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Kai Vehmanen]

On Thu, 14 Feb 2002, Kai Vehmanen wrote:

> 2.a) way to notice that an xrun has happened during b->c 
>   b) ability to reset the streams
> 3. way to make sure that engine->process() never takes longer
>    than period_time*number_of_periods

More debug information follows. I changed jackd code so that if the time 
between mmap_begin() -> mmap_commit() exceeds total amount of buffering, 
we do a forced restart.

Normal 'snd_pcm_drop() -> snd_pcm_prepare() -> snd_pcm_start()' sequence 
doesn't solve the problem. Audio is still garbled. I didn't try full 
'close() -> ... -> open() -> ..' cycle yet, as that would involve quite a 
lot of work (jackd's alsa_driver.c is a long piece of code).

What I did try was replacing drop() with snd_pcm_drain() and this resulted
in a hang (not a kernel hang, but process never returns to user-space) in
the driver level. Here's the backtrace:

#0  0x40127b54 in __ioctl () from /lib/libc.so.6
#1  0x401f9da0 in __DTOR_END__ () from /usr/lib/libasound.so.2
#2  0x401b0063 in snd_pcm_drain (pcm=0x805af58) at pcm.c:922
#3  0x401735eb in alsa_driver_audio_stop (driver=0x8053ec0) at alsa_driver.c:616
#4  0x401740c7 in alsa_driver_wait (driver=0x8053ec0) at alsa_driver.c:965

After this, jackd needs to be killed with SIGKILL.

-- 
 http://www.eca.cx
 Audio software for Linux!


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: [Jackit-devel] Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Jaroslav Kysela]

On Thu, 14 Feb 2002, Kai Vehmanen wrote:

> On Thu, 14 Feb 2002, Kai Vehmanen wrote:
>
> > 2.a) way to notice that an xrun has happened during b->c
> >   b) ability to reset the streams
> > 3. way to make sure that engine->process() never takes longer
> >    than period_time*number_of_periods
>
> More debug information follows. I changed jackd code so that if the time
> between mmap_begin() -> mmap_commit() exceeds total amount of buffering,
> we do a forced restart.
>
> Normal 'snd_pcm_drop() -> snd_pcm_prepare() -> snd_pcm_start()' sequence
> doesn't solve the problem. Audio is still garbled. I didn't try full
> 'close() -> ... -> open() -> ..' cycle yet, as that would involve quite a
> lot of work (jackd's alsa_driver.c is a long piece of code).
>
> What I did try was replacing drop() with snd_pcm_drain() and this resulted
> in a hang (not a kernel hang, but process never returns to user-space) in
> the driver level. Here's the backtrace:
>
> #0  0x40127b54 in __ioctl () from /lib/libc.so.6
> #1  0x401f9da0 in __DTOR_END__ () from /usr/lib/libasound.so.2
> #2  0x401b0063 in snd_pcm_drain (pcm=0x805af58) at pcm.c:922
> #3  0x401735eb in alsa_driver_audio_stop (driver=0x8053ec0) at alsa_driver.c:616
> #4  0x401740c7 in alsa_driver_wait (driver=0x8053ec0) at alsa_driver.c:965
>
> After this, jackd needs to be killed with SIGKILL.

I'm curious what is saying this command:

cat /proc/asound/card0/pcm0p/sub0/*

(replace card0 with affected card)

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Kai Vehmanen]

On Thu, 14 Feb 2002, Jaroslav Kysela wrote:

>> What I did try was replacing drop() with snd_pcm_drain() and this resulted
>> in a hang (not a kernel hang, but process never returns to user-space) in
>> the driver level. Here's the backtrace:
> I'm curious what is saying this command:
> cat /proc/asound/card0/pcm0p/sub0/*

Doh, I've totally forgot ALSA's proc entries. Anyways, here's the 
whole dump (status doesn't look good):

--cut--
status:

state: <NULL>
trigger_time: 1013709966.595600
tstamp      : 1013710109.203655
delay       : -6285920
avail       : 6287968
avail_max   : 6287968

hw_params:

access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (1445100000/32768)
period_size: 1024
buffer_size: 2048
tick_time: 10000

sw_params:

tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 1024
xfer_align: 1024
start_threshold: 4294967295
stop_threshold: 4294967295
silence_threshold: 0
silence_size: 0
boundary: 1073741824
--cut--

Status during normal processing (same exact setup):

--cut--
state: RUNNING
trigger_time: 1013710204.382739
tstamp      : 1013710213.136159
delay       : 1040
avail       : 1008
avail_max   : 1040
--cut--

-- 
 http://www.eca.cx
 Audio software for Linux!


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: [Jackit-devel] Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Paul Davis]

>Normal 'snd_pcm_drop() -> snd_pcm_prepare() -> snd_pcm_start()' sequence 
>doesn't solve the problem. Audio is still garbled. I didn't try full 
>'close() -> ... -> open() -> ..' cycle yet, as that would involve quite a 
>lot of work (jackd's alsa_driver.c is a long piece of code).

its my feeling that the error is in JACK somewhere. as far as i can
tell, the drop/prepare/start sequence restores the hw and driver to
the correct condition, but apparently not JACK's internals.

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Kai Vehmanen]

I think we can close this problem at least for now. The cause for the
garbled audio problem was found from JACK's side.

I'm still a bit puzzled why I didn't get xruns in the test case quoted
below, but until I can reproduce the problem, there's not much to discuss
about. But for the readers of alsa-devel archives, if you are having xrun
detection problems with ALSA mmap pcm API, do post a message about it. :)

On Thu, 14 Feb 2002, Kai Vehmanen wrote:

> - no xruns are detected even though after the timeout
>   alsa_driver_wait() took 56.4msec which is more than
>   period_size * number_of_periods (1024*2/44100*1000=46msec);
>   in other words there should have been an xrun

-- 
 http://www.eca.cx
 Audio software for Linux!


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Jaroslav Kysela]

On Tue, 19 Feb 2002, Kai Vehmanen wrote:

> I think we can close this problem at least for now. The cause for the
> garbled audio problem was found from JACK's side.
>
> I'm still a bit puzzled why I didn't get xruns in the test case quoted
> below, but until I can reproduce the problem, there's not much to discuss
> about. But for the readers of alsa-devel archives, if you are having xrun
> detection problems with ALSA mmap pcm API, do post a message about it. :)

You posted this sw params on alsa-devel a few days ago:

sw_params:

tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 1024
xfer_align: 1024
start_threshold: 4294967295
stop_threshold: 4294967295
silence_threshold: 0
silence_size: 0
boundary: 1073741824
--cut--

As you can see, the stop_threshold is set to UMAX_INT. In case when
stop_threshold is above ring buffer size, then it means for drivers: I
don't care about xruns, don't report them. The stop threshold must be
equal to ring buffer size to get xruns when no more frames are in ring
buffer.

> On Thu, 14 Feb 2002, Kai Vehmanen wrote:
>
> > - no xruns are detected even though after the timeout
> >   alsa_driver_wait() took 56.4msec which is more than
> >   period_size * number_of_periods (1024*2/44100*1000=46msec);
> >   in other words there should have been an xrun

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Kai Vehmanen]

On Tue, 19 Feb 2002, Jaroslav Kysela wrote:

>> I'm still a bit puzzled why I didn't get xruns in the test case quoted
>> below, but until I can reproduce the problem, there's not much to discuss
> You posted this sw params on alsa-devel a few days ago:
[....]
> sw_params:
> stop_threshold: 4294967295
[...]
> As you can see, the stop_threshold is set to UMAX_INT. In case when
> stop_threshold is above ring buffer size, then it means for drivers: I
> don't care about xruns, don't report them. The stop threshold must be
> equal to ring buffer size to get xruns when no more frames are in ring
> buffer.

Hmm, makes sense. This raises a few new questions:

1) Is 'avail > stop_threshold' the only condition when a stream 
   can move from RUNNING to XRUN state? The only places I located
   in the current source tree, where this state change happens, were
   in alsa-kernel/core/pcm_lib.c, functions 
   snd_pcm_update_hw_ptr_interrupt() and snd_pcm_update_hw_ptr(). 

2) If (1) is true, why does runnig jack produces xruns every 
   now and then...? The stop_threshold is UMAX_INT for 
   both directions and it should never occur that over 
   buffer_size samples is writable to, or readable from 
   the pcm device.

And to save your time ;), here's one possible explanation to (2):

Looking at jackd code, one possibility is that the we are only getting an
EPIPE from snd_pcm_avail_update(), but the stream is still in RUNNING 
state. At least in alsa-lib/src/pcm/pcm_hw.c:snd_pcm_hw_avail_update()
we have a test for:

--cut--
if (avail > pcm->buffer_size)
	return -EPIPE;
--cut--

This would trigger jackd's xrun handling code, but leave state to RUNNING.
Am I on the right track here?

-- 
 http://www.eca.cx
 Audio software for Linux!


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Jaroslav Kysela]

On Thu, 21 Feb 2002, Kai Vehmanen wrote:

> On Tue, 19 Feb 2002, Jaroslav Kysela wrote:
>
> >> I'm still a bit puzzled why I didn't get xruns in the test case quoted
> >> below, but until I can reproduce the problem, there's not much to discuss
> > You posted this sw params on alsa-devel a few days ago:
> [....]
> > sw_params:
> > stop_threshold: 4294967295
> [...]
> > As you can see, the stop_threshold is set to UMAX_INT. In case when
> > stop_threshold is above ring buffer size, then it means for drivers: I
> > don't care about xruns, don't report them. The stop threshold must be
> > equal to ring buffer size to get xruns when no more frames are in ring
> > buffer.
>
> Hmm, makes sense. This raises a few new questions:
>
> 1) Is 'avail > stop_threshold' the only condition when a stream
>    can move from RUNNING to XRUN state? The only places I located
>    in the current source tree, where this state change happens, were
>    in alsa-kernel/core/pcm_lib.c, functions
>    snd_pcm_update_hw_ptr_interrupt() and snd_pcm_update_hw_ptr().
>
> 2) If (1) is true, why does runnig jack produces xruns every
>    now and then...? The stop_threshold is UMAX_INT for
>    both directions and it should never occur that over
>    buffer_size samples is writable to, or readable from
>    the pcm device.
>
> And to save your time ;), here's one possible explanation to (2):
>
> Looking at jackd code, one possibility is that the we are only getting an
> EPIPE from snd_pcm_avail_update(), but the stream is still in RUNNING
> state. At least in alsa-lib/src/pcm/pcm_hw.c:snd_pcm_hw_avail_update()
> we have a test for:
>
> --cut--
> if (avail > pcm->buffer_size)
> 	return -EPIPE;
> --cut--
>
> This would trigger jackd's xrun handling code, but leave state to RUNNING.
> Am I on the right track here?

Yes, this condition is faulty. It should be 'avail >= pcm->stop_threshold'.
Fixed in CVS and thanks for verbose error detection.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Jaroslav Kysela]

On Thu, 21 Feb 2002, Jaroslav Kysela wrote:

> On Thu, 21 Feb 2002, Kai Vehmanen wrote:
>
> > On Tue, 19 Feb 2002, Jaroslav Kysela wrote:
> >
> > >> I'm still a bit puzzled why I didn't get xruns in the test case quoted
> > >> below, but until I can reproduce the problem, there's not much to discuss
> > > You posted this sw params on alsa-devel a few days ago:
> > [....]
> > > sw_params:
> > > stop_threshold: 4294967295
> > [...]
> > > As you can see, the stop_threshold is set to UMAX_INT. In case when
> > > stop_threshold is above ring buffer size, then it means for drivers: I
> > > don't care about xruns, don't report them. The stop threshold must be
> > > equal to ring buffer size to get xruns when no more frames are in ring
> > > buffer.
> >
> > Hmm, makes sense. This raises a few new questions:
> >
> > 1) Is 'avail > stop_threshold' the only condition when a stream
> >    can move from RUNNING to XRUN state? The only places I located
> >    in the current source tree, where this state change happens, were
> >    in alsa-kernel/core/pcm_lib.c, functions
> >    snd_pcm_update_hw_ptr_interrupt() and snd_pcm_update_hw_ptr().
> >
> > 2) If (1) is true, why does runnig jack produces xruns every
> >    now and then...? The stop_threshold is UMAX_INT for
> >    both directions and it should never occur that over
> >    buffer_size samples is writable to, or readable from
> >    the pcm device.
> >
> > And to save your time ;), here's one possible explanation to (2):
> >
> > Looking at jackd code, one possibility is that the we are only getting an
> > EPIPE from snd_pcm_avail_update(), but the stream is still in RUNNING
> > state. At least in alsa-lib/src/pcm/pcm_hw.c:snd_pcm_hw_avail_update()
> > we have a test for:
> >
> > --cut--
> > if (avail > pcm->buffer_size)
> > 	return -EPIPE;
> > --cut--
> >
> > This would trigger jackd's xrun handling code, but leave state to RUNNING.
> > Am I on the right track here?
>
> Yes, this condition is faulty. It should be 'avail >= pcm->stop_threshold'.
> Fixed in CVS and thanks for verbose error detection.

My initial fix wasn't very good. Although the corrected condition fixes
the XRUN detection, XRUN must be also propagated to the kernel space
allowing driver code to update the PCM state to XRUN. I've added a new
XRUN ioctl to the PCM kernel API, so everything should behave as expected
now.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle ofsnd_pcm_mmap_{begin,commit} ?

[Abramo Bagnara]

Jaroslav Kysela wrote:
> 
> On Thu, 21 Feb 2002, Kai Vehmanen wrote:
> 
> > On Tue, 19 Feb 2002, Jaroslav Kysela wrote:
> >
> > >> I'm still a bit puzzled why I didn't get xruns in the test case quoted
> > >> below, but until I can reproduce the problem, there's not much to discuss
> > > You posted this sw params on alsa-devel a few days ago:
> > [....]
> > > sw_params:
> > > stop_threshold: 4294967295
> > [...]
> > > As you can see, the stop_threshold is set to UMAX_INT. In case when
> > > stop_threshold is above ring buffer size, then it means for drivers: I
> > > don't care about xruns, don't report them. The stop threshold must be
> > > equal to ring buffer size to get xruns when no more frames are in ring
> > > buffer.
> >
> > Hmm, makes sense. This raises a few new questions:
> >
> > 1) Is 'avail > stop_threshold' the only condition when a stream
> >    can move from RUNNING to XRUN state? The only places I located
> >    in the current source tree, where this state change happens, were
> >    in alsa-kernel/core/pcm_lib.c, functions
> >    snd_pcm_update_hw_ptr_interrupt() and snd_pcm_update_hw_ptr().
> >
> > 2) If (1) is true, why does runnig jack produces xruns every
> >    now and then...? The stop_threshold is UMAX_INT for
> >    both directions and it should never occur that over
> >    buffer_size samples is writable to, or readable from
> >    the pcm device.
> >
> > And to save your time ;), here's one possible explanation to (2):
> >
> > Looking at jackd code, one possibility is that the we are only getting an
> > EPIPE from snd_pcm_avail_update(), but the stream is still in RUNNING
> > state. At least in alsa-lib/src/pcm/pcm_hw.c:snd_pcm_hw_avail_update()
> > we have a test for:
> >
> > --cut--
> > if (avail > pcm->buffer_size)
> >       return -EPIPE;
> > --cut--
> >
> > This would trigger jackd's xrun handling code, but leave state to RUNNING.
> > Am I on the right track here?
> 
> Yes, this condition is faulty. It should be 'avail >= pcm->stop_threshold'.
> Fixed in CVS and thanks for verbose error detection.

Perhaps I'm missing something, but I strongly disagree with your recent
changes on CVS:

- if avail > buffer_size this means either played garbage (playback) or
overwritten samples (capture). The return of an error is perfectly
sensible (also because the value returned would not have any sensible
meaning).

- the insertion of SND_PCM_IOCTL_XRUN is a nonsense, as the application
has explicitly asked to not stop the stream when xrun happens.

As a side note (and as a broken record :-( ), I'd like you don't change
the API without peer review. I hope you fully undertstand why...

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle ofsnd_pcm_mmap_{begin,commit} ?

[Kai Vehmanen]

On Thu, 21 Feb 2002, Abramo Bagnara wrote:

>>> if (avail > pcm->buffer_size)
>> Yes, this condition is faulty. It should be 'avail >= pcm->stop_threshold'.
> - if avail > buffer_size this means either played garbage (playback) or
> overwritten samples (capture). The return of an error is perfectly
> sensible (also because the value returned would not have any sensible
> meaning).

Hmm, the mmap semantics of stop_threshold should be similar to the 
read()/write() API.

The functions in alsa-kernel/core/pcm_lib.c seem to take care that
read/write don't access outside the buffer area. On the other hand it is
possible to process more bytes than buffer_size with one call.

Similarly the short pcm mmap example in the ALSA API documentation
(alsa-lib/src/pcm/pcm.c), can also handle situations where avail_update()  
reports more frames than buffer_size (as can happen after Jaroslav today's
changes). It always processes period_size at a time.

It's also true that without the change, stop_threshold didn't work
properly with mmap access.

Yes another pov is that Jaroslav changes might cause trouble to some
applications (at least jackd will require patching as it sets
stop_threshold to UINT_MAX - not a big thing in this case). Hmm, could
this cahnge result in accessing illegal memory areas in some
situations...?

> - the insertion of SND_PCM_IOCTL_XRUN is a nonsense, as the application
> has explicitly asked to not stop the stream when xrun happens.

It's only called if stop_threshold is set to buffer_size or lower (-> app
_has_ asked to stop if xrun occurs).

> As a side note (and as a broken record :-( ), I'd like you don't change
> the API without peer review. I hope you fully undertstand why...

I agree. Although as we are using CVS, changes are easy to take back.  
Official API is defined by the released versions. And of course in this
case the API change didn't break compatibility...

-- 
 http://www.eca.cx
 Audio software for Linux!


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle ofsnd_pcm_mmap_{begin,commit} ?

[Abramo Bagnara]

Kai Vehmanen wrote:
> 
> On Thu, 21 Feb 2002, Abramo Bagnara wrote:
> 
> >>> if (avail > pcm->buffer_size)
> >> Yes, this condition is faulty. It should be 'avail >= pcm->stop_threshold'.
> > - if avail > buffer_size this means either played garbage (playback) or
> > overwritten samples (capture). The return of an error is perfectly
> > sensible (also because the value returned would not have any sensible
> > meaning).
> 
> Hmm, the mmap semantics of stop_threshold should be similar to the
> read()/write() API.

And this was already true. If you use mmap or read/write is irrelevant
wrt stream stop in XRUN state.

> The functions in alsa-kernel/core/pcm_lib.c seem to take care that
> read/write don't access outside the buffer area. On the other hand it is
> possible to process more bytes than buffer_size with one call.
> 
> Similarly the short pcm mmap example in the ALSA API documentation
> (alsa-lib/src/pcm/pcm.c), can also handle situations where avail_update()
> reports more frames than buffer_size (as can happen after Jaroslav today's
> changes). It always processes period_size at a time.
> 
> It's also true that without the change, stop_threshold didn't work
> properly with mmap access.

??? Why you think that?

> 
> Yes another pov is that Jaroslav changes might cause trouble to some

Not "might", the change already now break all plugins!

> applications (at least jackd will require patching as it sets
> stop_threshold to UINT_MAX - not a big thing in this case). Hmm, could
> this cahnge result in accessing illegal memory areas in some
> situations...?
> 
> > - the insertion of SND_PCM_IOCTL_XRUN is a nonsense, as the application
> > has explicitly asked to not stop the stream when xrun happens.
> 
> It's only called if stop_threshold is set to buffer_size or lower (-> app
> _has_ asked to stop if xrun occurs).

The point is that alsa-lib will stop the stream also when application
has asked to *not* do that.

I call this a _broken_ behaviour, don't you?

That apart perhaps to have a snd_pcm_xrun call (to couple with
snd_pcm_drop and snd_pcm_drain) might be useful (who knows, I don't
believe, but...)

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle ofsnd_pcm_mmap_{begin,commit} ?

[Jaroslav Kysela]

On Thu, 21 Feb 2002, Abramo Bagnara wrote:

> Kai Vehmanen wrote:
> >
> > On Thu, 21 Feb 2002, Abramo Bagnara wrote:
> >
> > >>> if (avail > pcm->buffer_size)
> > >> Yes, this condition is faulty. It should be 'avail >= pcm->stop_threshold'.
> > > - if avail > buffer_size this means either played garbage (playback) or
> > > overwritten samples (capture). The return of an error is perfectly
> > > sensible (also because the value returned would not have any sensible
> > > meaning).
> >
> > Hmm, the mmap semantics of stop_threshold should be similar to the
> > read()/write() API.
>
> And this was already true. If you use mmap or read/write is irrelevant
> wrt stream stop in XRUN state.

Right, but the stream is RUNNING. My change does nothing else than
checking if an xrun state occured in the user space and synchronizes
the kernel code with this situation. Definitely the PCM state should be
XRUN not RUNNING when snd_pcm_avail_update() returns -EPIPE. It was very
misleading for application to receive these broken results.

> > The functions in alsa-kernel/core/pcm_lib.c seem to take care that
> > read/write don't access outside the buffer area. On the other hand it is
> > possible to process more bytes than buffer_size with one call.
> >
> > Similarly the short pcm mmap example in the ALSA API documentation
> > (alsa-lib/src/pcm/pcm.c), can also handle situations where avail_update()
> > reports more frames than buffer_size (as can happen after Jaroslav today's
> > changes). It always processes period_size at a time.
> >
> > It's also true that without the change, stop_threshold didn't work
> > properly with mmap access.
>
> ??? Why you think that?
>
> >
> > Yes another pov is that Jaroslav changes might cause trouble to some
>
> Not "might", the change already now break all plugins!
>
> > applications (at least jackd will require patching as it sets
> > stop_threshold to UINT_MAX - not a big thing in this case). Hmm, could
> > this cahnge result in accessing illegal memory areas in some
> > situations...?
> >
> > > - the insertion of SND_PCM_IOCTL_XRUN is a nonsense, as the application
> > > has explicitly asked to not stop the stream when xrun happens.
> >
> > It's only called if stop_threshold is set to buffer_size or lower (-> app
> > _has_ asked to stop if xrun occurs).
>
> The point is that alsa-lib will stop the stream also when application
> has asked to *not* do that.

??? Can you explain it?

> I call this a _broken_ behaviour, don't you?
>
> That apart perhaps to have a snd_pcm_xrun call (to couple with
> snd_pcm_drop and snd_pcm_drain) might be useful (who knows, I don't
> believe, but...)

We need this ioctl, because the user space code can't manage PCM state
for driver devices.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle ofsnd_pcm_mmap_{begin,commit} ?

[Abramo Bagnara]

Jaroslav Kysela wrote:
> 
> > > Hmm, the mmap semantics of stop_threshold should be similar to the
> > > read()/write() API.
> >
> > And this was already true. If you use mmap or read/write is irrelevant
> > wrt stream stop in XRUN state.
> 
> Right, but the stream is RUNNING. My change does nothing else than
> checking if an xrun state occured in the user space and synchronizes
> the kernel code with this situation. Definitely the PCM state should be
> XRUN not RUNNING when snd_pcm_avail_update() returns -EPIPE. It was very
> misleading for application to receive these broken results.

I've thought more about this and I'm happy to say that I think you're
right about your patch.

This change a bit the "when" part of xrun detection (previously was
doable only by kernel space), but once documentented I think it's
correct.

I still have doubts about snd_pcm_avail_update return value.

Should it return a value > buffer_size when stop_threshold is high?

Actually snd_pcm_mmap_begin automatically will reduce this amount to
contiguous size...

So yes, I think it's a good work. At the time of the first reading it
looked awful at my eyes, but now I've seen the light.

Sorry for the noise.

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle ofsnd_pcm_mmap_{begin,commit} ?

[Jaroslav Kysela]

On Thu, 21 Feb 2002, Kai Vehmanen wrote:

> On Thu, 21 Feb 2002, Abramo Bagnara wrote:
>
> >>> if (avail > pcm->buffer_size)
> >> Yes, this condition is faulty. It should be 'avail >= pcm->stop_threshold'.
> > - if avail > buffer_size this means either played garbage (playback) or
> > overwritten samples (capture). The return of an error is perfectly
> > sensible (also because the value returned would not have any sensible
> > meaning).
>
> Hmm, the mmap semantics of stop_threshold should be similar to the
> read()/write() API.

I fully agree here.

> The functions in alsa-kernel/core/pcm_lib.c seem to take care that
> read/write don't access outside the buffer area. On the other hand it is
> possible to process more bytes than buffer_size with one call.
>
> Similarly the short pcm mmap example in the ALSA API documentation
> (alsa-lib/src/pcm/pcm.c), can also handle situations where avail_update()
> reports more frames than buffer_size (as can happen after Jaroslav today's
> changes). It always processes period_size at a time.
>
> It's also true that without the change, stop_threshold didn't work
> properly with mmap access.
>
> Yes another pov is that Jaroslav changes might cause trouble to some
> applications (at least jackd will require patching as it sets
> stop_threshold to UINT_MAX - not a big thing in this case). Hmm, could
> this cahnge result in accessing illegal memory areas in some
> situations...?

I don't think. There is only a little complicated case when mmap_emulation
is active over read()/write() operations. There is a call to snd_pcm_read_mmap()
function with size >= buffer_size, but there is already a condition to
transfer contiguous memory areas, so everything should be ok (the stream
should forward itself to corrent appl_ptr).

> > - the insertion of SND_PCM_IOCTL_XRUN is a nonsense, as the application
> > has explicitly asked to not stop the stream when xrun happens.
>
> It's only called if stop_threshold is set to buffer_size or lower (-> app
> _has_ asked to stop if xrun occurs).

Yes.

> > As a side note (and as a broken record :-( ), I'd like you don't change
> > the API without peer review. I hope you fully undertstand why...
>
> I agree. Although as we are using CVS, changes are easy to take back.
> Official API is defined by the released versions. And of course in this
> case the API change didn't break compatibility...

I don't see any error as Abramo mentioned.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Kai Vehmanen]

On Thu, 21 Feb 2002, Jaroslav Kysela wrote:

> Yes, this condition is faulty. It should be 'avail >= pcm->stop_threshold'.

Btw; shouldn't that be 'avail > pcm->stop_threshold'...? For
     instance if you want to prefill playback buffers
     with silence before starting processing, you must be able
     to write buffer_size==stop_threshold frames of data.

-- 
 http://www.eca.cx
 Audio software for Linux!


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Jaroslav Kysela]

On Thu, 21 Feb 2002, Kai Vehmanen wrote:

> On Thu, 21 Feb 2002, Jaroslav Kysela wrote:
>
> > Yes, this condition is faulty. It should be 'avail >= pcm->stop_threshold'.
>
> Btw; shouldn't that be 'avail > pcm->stop_threshold'...? For
>      instance if you want to prefill playback buffers
>      with silence before starting processing, you must be able
>      to write buffer_size==stop_threshold frames of data.

Yes, but in this case avail == 0, so the XRUN doesn't occur. But it's
true, that the check for XRUN should be active only when PCM state is
RUNNING. I'll correct it soon.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Kai Vehmanen]

On Thu, 21 Feb 2002, Jaroslav Kysela wrote:

>> Btw; shouldn't that be 'avail > pcm->stop_threshold'...? For
> Yes, but in this case avail == 0, so the XRUN doesn't occur. But it's
> true, that the check for XRUN should be active only when PCM state is
> RUNNING. I'll correct it soon.

Ok, sounds good. One thing to remember is that if stream is already in
XRUN state, snd_pcm_hw_avail_update() should always return -EPIPE.

-- 
 http://www.eca.cx
 Audio software for Linux!


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Kai Vehmanen]

Answering to my own mail...

> Looking at jackd code, one possibility is that the we are only getting an
> EPIPE from snd_pcm_avail_update(), but the stream is still in RUNNING 
> state. At least in alsa-lib/src/pcm/pcm_hw.c:snd_pcm_hw_avail_update()
> we have a test for:
[...]
> if (avail > pcm->buffer_size)
> 	return -EPIPE;

This seems to be the case. It does look very unlikely that an xrun 
could go unnoticed. It would take quite a latency spike to 
allow hw_ptr to wrap around pcm->boundary. :)

I guess more probable explanation is something like:

loop:
    start = timer()
    poll()
    <interrupt -> hw_ptr += period_size>
    snd_pcm_avail_update()
    snd_pcm_mmap_begin()
    ...
    snd_pcm_mmap_commit()
    <interrupt -> hw_ptr += period_size>
    stop = timer()

If the interrupts occur at the right time, 'stop-start' 
might exceed 'period_time * period_count' even though 
snd_pcm_avail_update() never returns EPIPE. This is
probably what I saw when debugging jackd (and is, of
course, perfectly legal).

-- 
 http://www.eca.cx
 Audio software for Linux!


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: should i be able to abort in the middle of snd_pcm_mmap_{begin,commit} ?

[Abramo Bagnara]

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?
> 
> 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.

Do you mean:

snd_pcm_mmap_begin
snd_pcm_drop
snd_pcm_mmap_commit

sequence?

If yes, it does not work, you need to call snd_pcm_mmap_begin again
after snd_pcm_drop.

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel