Avuton Olrich | 2 Jul 05:20 2008
Picon

Problems getting realtime recording.

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
(Continue reading)

Kai Vehmanen | 2 Jul 23:11 2008

Re: Problems getting realtime recording.

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.

(Continue reading)

Kai Vehmanen | 2 Jul 23:13 2008

Re: starting with pyeca : exception error

Hi,

On Sat, 7 Jun 2008, Alexandre Korber wrote:

>>>> import pyeca
>>>> e = pyeca.ECA_CONTROL_INTERFACE()
[...]
> (to get rid of this message, pass zero to instance init)
> Exception exceptions.AttributeError: "'NoneType' object has no attribute 'maxint'" in <bound method
Popen3.__del__ of <popen2.Popen3 instance at 0x7fc729530dd0>> ignored

this sounds a lot like a problem with pyeca and your version/installation
of python. Which version of python are you using?

--

-- 

-------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list

Kai Vehmanen | 3 Jul 02:00 2008

preparing for release: 2.4.7pre1_2.5.0

Hi,

I'm again trying to concentrate my efforts on getting 2.5.0 released. 
Things are looking pretty good at this point, but as so much time has 
passed since the last release, some extra last minute testing would not 
hurt. So here's a link to a prerelease tarball:

http://ecasound.seul.org/download/snapshots/ecasound-2.4.7pre1_2.5.0.tar.gz

** Note for potential testers! **
Everyone who gives the prerelease(s) a test run and provides some kind of
feedback to the list, will be mentioned in a special "last minute 
release test participants" section in the official release notes. :)

To be realistic, Ecasound is not the hottest project around in the open 
source world ;), so getting people to test it is not easy. And this is 
completely understandable, or should I even say preferable (I really do 
hope that most of you are happy with whatever version of ecasound that 
comes with your distribution of choice). I'm not sure if getting to the 
release notes is enough of a incentive to get involved, but if I can get 
one extra tester this way, I'm happy! :)

Btw, Ecasound is getting old (or about to hit the open-source teens, 
which ever way you look at it) -- it's going to be 10 years since the 
first public GPL release in June next year, wow!

But back to business. Comments are also welcome to below release 
related texts.

Freshmeat compatible changes summary:
(Continue reading)

Linux Media | 3 Jul 04:15 2008
Picon

Re: preparing for release: 2.4.7pre1_2.5.0

Kai Vehmanen wrote:
> I'm again trying to concentrate my efforts on getting 2.5.0 released. 
> Things are looking pretty good at this point, but as so much time has 
> passed since the last release, some extra last minute testing would not 
> hurt. So here's a link to a prerelease tarball:
> 
> http://ecasound.seul.org/download/snapshots/ecasound-2.4.7pre1_2.5.0.tar.gz

Great new features!!!

I built ecasound and after a quick test to make sure it's installed and 
running, I am ready to test the new features.

> To be realistic, Ecasound is not the hottest project around in the open 
> source world ;), so getting people to test it is not easy. And this is 
> completely understandable, or should I even say preferable (I really do 
> hope that most of you are happy with whatever version of ecasound that 
> comes with your distribution of choice). I'm not sure if getting to the 
> release notes is enough of a incentive to get involved, but if I can get 
> one extra tester this way, I'm happy! :)

I don't know what other people think about ecasound, but when I first 
started using it about 5 years ago, it became (and has remained) my 
favorite linux program. And that's *not* an exaggeration.

I'm testing because I'm excited about the new features. This will not be 
a "sacrifice" of my time because I'm looking forward to it, and am 
fueled with enthusiasm.

> But back to business. Comments are also welcome to below release 
(Continue reading)

Andrew Lees | 3 Jul 09:17 2008
Picon

Re: Problems getting realtime recording.

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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Dubphil | 3 Jul 09:46 2008
Picon

Re: preparing for release: 2.4.7pre1_2.5.0

Hello !

> Btw, Ecasound is getting old (or about to hit the open-source teens,
> which ever way you look at it) -- it's going to be 10 years since the
> first public GPL release in June next year, wow!

congrats for such a longevity !

Ecasound is simply the center piece of my soundsystem. for your curiosity
here is the scheme :

         .... midi gear(2)...(clock)... vintage synth(1)
         :                                 |
       seq24 ..... linuxsampler ------ ECASOUND(+ LADSPA plugins) ....
midi gear(3)
         :......... specimen(5)----------'  |
                                            ---- jackd -> recording/output

legend:
----- audio
..... midi

What about the "cs-reload" ability ?

I will test the 2.4.7 surely :)

Thousand thanks for this jewel piece of software !

Philippe

-------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list

Avuton Olrich | 3 Jul 12:33 2008
Picon

Re: Problems getting realtime recording.

On Wed, Jul 2, 2008 at 2:11 PM, Kai Vehmanen <kvehmanen <at> eca.cx> 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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list

Linux Media | 3 Jul 13:01 2008
Picon

Re: preparing for release: 2.4.7pre1_2.5.0

> I just have one errand to run in town and I will start testing the new 
> features when I'm back.

I've tested all the features in "Manipulating objects - looping, 
reversing, ..." section. I've even done some pretty amazing things (like 
using the 'loop device' to get the same audio file to play different 
segments at different times) and haven't found a bug.

One question...

In the following...
-i:select,start-time,duration,file.ext,params
What 'params' are you referring to? Can you give me an example?

Thanks,
Rocco

-------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list

Kai Vehmanen | 3 Jul 17:58 2008

Re: preparing for release: 2.4.7pre1_2.5.0

Hi,

thanks all for the quick feedback!

On Thu, 3 Jul 2008, Linux Media wrote:

> I've tested all the features in "Manipulating objects - looping,
> reversing, ..." section. I've even done some pretty amazing things (like
> using the 'loop device' to get the same audio file to play different
> segments at different times) and haven't found a bug.

Now that's reassuring to hear! The code for 'audioloop', 'select' et all 
is now fully shared with the (new) EWF implementation, so this release 
actually has less code and more releases.

> In the following...
> -i:select,start-time,duration,file.ext,params
> What 'params' are you referring to? Can you give me an example?

That can be any params given to 'file.ext'. For instance if you want to 
use libsndfile to open a RIFF WAVE file (use libsndfile instead ecasound's 
own implementation), you'd use "-i:sndfile,foo.wav".

So with 'select' this would look like:

-i:select,10,20,sndfile,foo.wav

... basicly you can freely "stack" the audio ops one after another. 
Probably biggest bottleneck is readability. ;)

I've also added a lot more sanity checks to warn (or sometimes, even raise 
an error) about cases where the result might not be what the user 
initially excepted. One example is trying to loop a 'null' object. This 
won't simply work as 'null' has no finite length:

ecasound -i audioloop,null -o alsa

... will now raise an error. I'm planning to add more of these. 
For instance the following should raise an error, but doesn't do 
it yet:

ecasound -i select,10,20,foo.m4a -o alsa

Seeking is not supported with AAC/MPEG4 inputs, so selecting a range is 
not possible. Unfortunately ecasound just silently accepts the above and 
plays out 'foo.m4a'.

One problem with adding these checks is that it is really difficult to 
think of all possible use-scenarios and there's a big risk that you 
prevent some valid use-case by adding sanitiy checks. Thus I prefer to add 
warnings, and only in clear case raise an actual error.

--

-- 

-------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list


Gmane