Problems getting realtime recording.

[Avuton Olrich]

Running v2.6.25.8-rt7 (and other kernels I have tried) and recording
with ecasound I'm getting messages like:

warning! playback overrun - samples lost!  Break was at least
1214667212122.58 ms long.

Could this be a false alarm?

I have also gotten the following error message (repeated many times):

Unknown device state '3'

This one causes recording to stop, for sure.

Any idea how to track down these issues?

Thanks!
--
avuton
--
 "I've got a fever. And the only prescription is more cowbell." --
Christopher Walken

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Kai Vehmanen]

Hi,

On Tue, 1 Jul 2008, Avuton Olrich wrote:

> Running v2.6.25.8-rt7 (and other kernels I have tried) and recording
> with ecasound I'm getting messages like:
[...]
> warning! playback overrun - samples lost!  Break was at least
> 1214667212122.58 ms long.

actually you've discovered a _very_ old (more than six years at least) bug
in the warning message (just in the message). The above should say "record
overrun". I actually update the whole message in the current devel tree
to:

"WARNING: ALSA recording overrun, some audio samples were lost!"

... so there has been a too long break in process scheduling and some
recorded samples were lost. The reason is either:

  a) too little buffers in the audio driver/hw (try -z:intbuf)
  b) kernel scheduling issue
  c) bug in ALSA or the specific driver

> Could this be a false alarm?

I've afraid not. When the above is printed out, some samples where most
probably really lost in the recorded audio streams. The same message
should print out the duration of the break.

If you want ecasound to stop processing and exit when an xrun happens,
specify -z:xruns.

> I have also gotten the following error message (repeated many times):
>
> Unknown device state '3'

That suggests something fishy going on with the ALSA driver. State '3'
is an ALSA enum "SND_PCM_STATE_RUNNING", i.e. everything is ok. But what's
weird is that the above message from ecasound is printed when ALSA returns
an error when reading audio data, but the device state is not "XRUN"
(underrun has occured) nor "SUSPENDED". So it would suggest that something
has gone bad at the driver level.

> This one causes recording to stop, for sure.

Which would match with my hypothesis about things going bad on driver
level.

--


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Andrew Lees-2]

On Tue, 2008-07-01 at 20:20 -0700, Avuton Olrich wrote:

Running v2.6.25.8-rt7 (and other kernels I have tried) and recording
with ecasound I'm getting messages like:

I have had serious problems, including recording failures and kernel oops/lockups with alsa and kernel 2.6.25, such that I've reverted to 2.6.24 for now.  I had neither time nor expertise to track the issues down, but figured I'd try again in a little while and see if it was more than a temporary issue.  I too got those huge break numbers, but if you avoid real time (use nice and more buffering), you may find they become more sensible.  Irrespective of scheduling choices, though, the system was still unstable.  Problems of various types occurred with all alsa input use, not only ecasound, so it was clearly a kernel/driver issue.  I was using the usb driver with a creative external device.

2.6.25-tuxonice-r4 was unstable, 2.6.24-gentoo-r8 works without a hitch, same alsa library, same user level software, same kernel compile config.

warning! playback overrun - samples lost!  Break was at least
1214667212122.58 ms long.

Could this be a false alarm?

I have also gotten the following error message (repeated many times):

Unknown device state '3'

This one causes recording to stop, for sure.

Any idea how to track down these issues?

Thanks!

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Avuton Olrich]

On Wed, Jul 2, 2008 at 2:11 PM, Kai Vehmanen <kvehmanen@...> wrote:

> actually you've discovered a _very_ old (more than six years at least) bug
> in the warning message (just in the message). The above should say "record
> overrun". I actually update the whole message in the current devel tree
> to:
>
> "WARNING: ALSA recording overrun, some audio samples were lost!"
>
> ... so there has been a too long break in process scheduling and some
> recorded samples were lost. The reason is either:
>
>  a) too little buffers in the audio driver/hw (try -z:intbuf)
>  b) kernel scheduling issue
>  c) bug in ALSA or the specific driver

OK, I actually have z:intbuf enabled. It's some kernel oddity. Is
there a way I can get the system time an overrun occurs?

>> I have also gotten the following error message (repeated many times):
>>
>> Unknown device state '3'
>
> That suggests something fishy going on with the ALSA driver. State '3'
> is an ALSA enum "SND_PCM_STATE_RUNNING", i.e. everything is ok. But what's
> weird is that the above message from ecasound is printed when ALSA returns
> an error when reading audio data, but the device state is not "XRUN"
> (underrun has occured) nor "SUSPENDED". So it would suggest that something
> has gone bad at the driver level.

Oh, in that case, I reverted to 2.6.24 (as recommended by Andrew Lees)
(was using 2.6.22 before this, and I guess I'll revert to that if this
continues to be an issue).

Thanks for the help
--
avuton
--
 "I've got a fever. And the only prescription is more cowbell." --
Christopher Walken

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Avuton Olrich]

On Tue, Jul 1, 2008 at 8:20 PM, Avuton Olrich <avuton@...> wrote:
> Unknown device state '3'

I found out what this is caused by, but I have no idea why. This was
caused by me adding this to the command line:
-b:4096

Once I take that out I no longer get errored out that way.
--
avuton
--
 "I've got a fever. And the only prescription is more cowbell." --
Christopher Walken

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list