headers
Dan | 1 Dec 2004 14:08
Favicon

Big buffer needed for net recording

Hi,
  I'm using ecasound in a front end I wrote for home recording (thanks
Kai!) The computer is a silent no moving parts VIA box that just takes the
88/24 data and puts it on the lan. The problem is that ecasound is
really finicky about having an output file on the lan. I'm producing about
1/2 MB/s, but over wireless lan (throughput of several MB/s) it would get
disk overruns. I put a huge buffer in there (-z:db,100000 or something) but
still trouble. I went to 100 M bit lan, and I only get reliable performance
with another monstrous buffer.

  I dug into the data writing code, it seems that (but I'm not sure) the
software gets upset if there is any data left to be written, the next
time it comes around. Is there a mode I can turn on to make it less
sensitive? Or is anything else going on, any help?

  A second question, I tried using named pipes for flac files (the built in
flac isn't working very well), but it get's upset at the pipes. Either
it complains about 'fseek' errors and doesn't do anything, or it produces
incomplete flac files. The builtin flac seems to produce bad files, or
other weird problems.

Thanks for any help!

Dan

--
To unsubscribe send message 'unsubscribe' in the body of the
message to <ecasound-list-request <at> wakkanet.fi>.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dubphil | 3 Dec 2004 13:08
Picon
Favicon

Strange ecasound behavior

Hello,

I have to report a strange behaviour of ecasound :

I run ecasound like this :

ecasound -a:1,2,3,4 -i jack /
-a:1 -efl:300 -o jack /
-a:2 -efb:500,400 -o jack /
-a:3 -efb:1000,600 -o jack /
-a:4 -efh:1300 -o jack

thanks to qjackctl, I route TerminatorX to the ecasound input,
and I route the 4 ecasound outputs to ardour.

Everything goes well as long as, i suspect, an audio
signal is received by ecasound. When the sample stop in TerminatorX,
jack is struggling with xruns and if I don't play another sample in
a short time, ardour disconnect from Jack and everything crash !
This behaviour hapens both with the DeMuDi and AudioSlack distros.

The lonely trick I've found is to permanently connect my capture
channel output to the ecasound input :-( but I need this channel in
order to connect my TB303 and I don't want it to be processed by
ecasound.

Am'I missing something ? Is this something logical from ecasound ?
Or it should worth a bug report ?

Regards
(Continue reading)

Permalink | Reply | 11 comments |
headers
Paul Winkler | 3 Dec 2004 15:55
Favicon

Re: Strange ecasound behavior

On Fri, Dec 03, 2004 at 12:08:46PM -0000, Dubphil wrote:
(snip)
> Am'I missing something ? Is this something logical from ecasound ?
> Or it should worth a bug report ?

Are you sure it's ecasound that's misbehaving?
One way to check would be to use qjackctl to connect
terminatorX directly to 4 channels of ardour, not running
ecasound at all.  If that still has the same problem,
then you may have found a problem with terminatorX's jack support.

Also try your original setup with a different source than
terminatorX... any jack client that you know works ok with ardour.

--

-- 

Paul Winkler
http://www.slinkp.com

--
To unsubscribe send message 'unsubscribe' in the body of the
message to <ecasound-list-request <at> wakkanet.fi>.
Permalink | Reply | 4 comments |
headers
Dubphil | 3 Dec 2004 18:12
Picon
Favicon

Re: Strange ecasound behavior

> Are you sure it's ecasound that's misbehaving?

quite sure :)

> One way to check would be to use qjackctl to connect
> terminatorX directly to 4 channels of ardour, not running
> ecasound at all.

I've tried this of course and the problem doesn't occur.

> Also try your original setup with a different source than
> terminatorX... any jack client that you know works ok with ardour.

but remember that if I both connect the capture and TerminatorX to the
ecasound input it works like a charm even if terminatorX is not playing
but with terminatoreX alone, when it stops to play the xruns appear.
this fact is not in favor to ecasound :)

nevertheless I will try with qsynth and tell the result...

Thanks

Philippe

--
To unsubscribe send message 'unsubscribe' in the body of the
message to <ecasound-list-request <at> wakkanet.fi>.
Permalink | Reply | 3 comments |
headers
Dubphil | 3 Dec 2004 21:59
Picon
Favicon

Re: Strange ecasound behaviour

> nevertheless I will try with qsynth and tell the result...
>

I have tried with Qsynth and the behaviour is the same.
here is how I manage to get the xruns :

1 - open Qjackctl and start jackdjack

2 - open Qsynth

3 - run ecasound with the command :

ecasound -a:1,2,3,4 -i jack /
-a:1 -efl:300 -o jack /
-a:2 -efb:500,400 -o jack /
-a:3 -efb:1000,600 -o jack /
-a:4 -efh:1300 -o

4 - open ardour and the file that connects ardour to ecasound via jack

connections are :

eca-out-1&2 -> ardour-in-1&2 -> ardour-master
eca-out-3&4&5&6 -> ardour-in-3&4 -> ardour-master
eca-out-7&8 -> ardour-in-5&6 -> ardour-master
eca-out-3&4 -> ardour-in-7&8 -> ardour-bus-effect-1 -> ardour-master
eca-out-5&6 -> ardour-in-9&10 -> ardour-bus-effect-1 -> ardour-master
eca-out-7&8 -> ardour-in-11&12 -> ardour-bus-effect-1 -> ardour-master

5 - disconnect Qsynth from alsa-pcm playback out
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Vehmanen | 3 Dec 2004 22:20

Re: Strange ecasound behavior

On Fri, 3 Dec 2004, Dubphil wrote:

> but remember that if I both connect the capture and TerminatorX to the
> ecasound input it works like a charm even if terminatorX is not playing
> but with terminatoreX alone, when it stops to play the xruns appear.
> this fact is not in favor to ecasound :)

How about if you connect a dummy-client to the ecasound inputs, instead of 
capture ports - for example:

ecasound -i null -o jack -G:jack,dummyeca

--

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

--
To unsubscribe send message 'unsubscribe' in the body of the
message to <ecasound-list-request <at> wakkanet.fi>.
Permalink | Reply | 1 comment |
headers
Kai Vehmanen | 3 Dec 2004 22:50

Re: Strange ecasound behavior

Hello, 

I'll cc this to jackit-devel as I suspect this could be a libjack
problem.

On Fri, 3 Dec 2004, Dubphil wrote:
> I run ecasound like this :
> 
> ecasound -a:1,2,3,4 -i jack /
> -a:1 -efl:300 -o jack /
> -a:2 -efb:500,400 -o jack /
> -a:3 -efb:1000,600 -o jack /
> -a:4 -efh:1300 -o jack
> 
> thanks to qjackctl, I route TerminatorX to the ecasound input,
> and I route the 4 ecasound outputs to ardour.
> 
> Everything goes well as long as, i suspect, an audio
> signal is received by ecasound. When the sample stop in TerminatorX,
> jack is struggling with xruns and if I don't play another sample in
> a short time, ardour disconnect from Jack and everything crash !
> This behaviour hapens both with the DeMuDi and AudioSlack distros.

Ok, and based on your later message, replacing TerminatorX with QSynth 
gives similar results, so it's not a TerminatorX problem.

And Ecasound gets zombified when this happens. 

Anyway, I suspect that this is a problem in libjack. What essentially 
happens is that...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Winkler | 3 Dec 2004 23:45
Favicon

Re: Strange ecasound behavior

On Fri, Dec 03, 2004 at 11:50:24PM +0200, Kai Vehmanen wrote:
> Anyway, I suspect that this is a problem in libjack. What essentially 
> happens is that...
> 
> - you setup a subchain jackd->terX->ecasound->ardour->jackd
> - terX quits

I read his original post as "terX stops producing sound"
rather than "terX quits".  Was I mistaken?

> - jackd needs to reorganize the subchains so that jackd->ecasound
>   starts the updated chain
> - ... but jackd produces lots of xruns and ecasound is zombified

--

-- 

Paul Winkler
http://www.slinkp.com

--
To unsubscribe send message 'unsubscribe' in the body of the
message to <ecasound-list-request <at> wakkanet.fi>.
Permalink | Reply | 0 comments |
headers
Dubphil | 4 Dec 2004 00:49
Picon
Favicon

Re: Strange ecasound behavior

> How about if you connect a dummy-client to the ecasound inputs, instead of
> capture ports - for example:
>
> ecasound -i null -o jack -G:jack,dummyeca
>

when the setup is complete (review my last post) and when I have the
capture ports connected to ecasound every thing goes fine.
When I disconnect the capture ports, the Xruns start and my dummyeca escape
but if I reconnect Specimen (for exemple it's what I did) the Xruns stop.

other case :

setup complete, I connect dummyeca before diconnecting the capture ports,
then when I disconnect the capture ports dummyeca escape and the Xruns
start.

It would has been great if I could have replaced the capture ports by a
Dummy output. Nevertheless I will be able to connect a synth or something
that I will not use in order do keep ecasound happy :)

Thanks

Philippe

--
To unsubscribe send message 'unsubscribe' in the body of the
message to <ecasound-list-request <at> wakkanet.fi>.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dubphil | 4 Dec 2004 00:57
Picon
Favicon

Re: Strange ecasound behavior

> Hello,
>
> I'll cc this to jackit-devel as I suspect this could be a libjack
> problem.
>
> On Fri, 3 Dec 2004, Dubphil wrote:
>> I run ecasound like this :
>>
>> ecasound -a:1,2,3,4 -i jack /
>> -a:1 -efl:300 -o jack /
>> -a:2 -efb:500,400 -o jack /
>> -a:3 -efb:1000,600 -o jack /
>> -a:4 -efh:1300 -o jack
>>
>> thanks to qjackctl, I route TerminatorX to the ecasound input,
>> and I route the 4 ecasound outputs to ardour.
>>
>> Everything goes well as long as, i suspect, an audio
>> signal is received by ecasound. When the sample stop in TerminatorX,
>> jack is struggling with xruns and if I don't play another sample in
>> a short time, ardour disconnect from Jack and everything crash !
>> This behaviour hapens both with the DeMuDi and AudioSlack distros.
>
> Ok, and based on your later message, replacing TerminatorX with QSynth
> gives similar results, so it's not a TerminatorX problem.
>
> And Ecasound gets zombified when this happens.
>
> Anyway, I suspect that this is a problem in libjack. What essentially
> happens is that...
(Continue reading)

Permalink | Reply | 0 comments |

Gmane