help with delayed (15s) audio in ecasound crossover setup

[Gordon C]

Hi, I need a little help finding the cause of some very delayed audio. In this case 'very' means not just milliseconds, but in the order of 15 seconds or so. The extra challenge has been that about half the time (same hardware, same software, same settings, same music files) there is no delay at all. If it can work perfectly half the time, it ought to work perfectly the other half too!

My set-up is a desktop with Ubuntu 14.4 with Ecasound set up as the active crossover (pulseaudio and alsa are also involved). The long delay occurs with various audio sources (rhythmbox, youtube, VLC, netflix) so I don't think those are the problem.

I'm not sure what to be looking for as a cause. I don't see any obvious errors in logs. Is this a 'buffer' type of issue? Where/how would I look to see if that were the case?

thanks for any advice,

Gordon

 

[jplesset]

Might help to see your command line. Ecasound does have buffers, and you can change the buffer size, though 15 seconds is a very large buffer. I've tried buffers up to a couple seconds, and in my rig, shorter works just fine...

 

[CharlieLaub]

If you are not explicitly telling ecasound how much buffering to use it might be making up its own mind.

Try adding

-B:rt

to the beginning of your ecasound command text.

You might find a read of the ecasound manpage to be informative:
https://ecasound.seul.org/ecasound/Documentation/ecasound_manpage.html

 

[phofman]

The long delay occurs with various audio sources (rhythmbox, youtube, VLC, netflix)

Perhaps all of those player are playing internet streams from unreliable network? That would be the most likely explanation...

 

[Gordon C]

Hi, thanks for the responses.

Although ecasound is the crossover I can't say for sure that it is the problem. The sequence is Rhythmbox (playing a flac file from the hard-drive), alsa, ecasound, and pulseaudio ( I hope I've got that straight). And somewhere along the line there is (sometimes) a 15 second delay. I don't think it could be a network issue. (My crossover at the moment is:

ecasound -d:2 -n:3way-20Hzhighpass-bassshelf \
-B:rt -z:mixmode,sum -f:16,2,44100 \
-are,subs -i:alsahw,2,1,0 \
-are -el:RTlr4hipass,100 -o:loop,1 \
-a:mids,tweeters -i:loop,1 \
-a:subs -el:RTlr4lowpass,100 -el:RTlr4hipass,20 -el:RTlowshelf,2,50,0.71 -chorder:0,0,0,0,1,2 \
-a:mids -el:RTlr4lowpass,2000 -chorder:0,0,1,2,0,0 \
-a:tweeters -el:RTlr4hipass,2000 -chorder:1,2,0,0,0,0 \
-a:tweeters,mids,subs -f:16,6,44100 -o:loop,2 \
-a:delay -i:loop,2 -el:mTAP,1.9,1.9,0,0,0,0 -o:alsa

so it's always been set at -B:rt. Is there anythings else drastically wrong in there? (in a filter sense it's a pretty crude approximation I know, speakers have not been measured yet).

Most things I've found on audio delay are talking about milliseconds, so a 15 second delay is pretty drastic. Does each element in the chain (Rhythmbox (playing a flac file), alsa, ecasound, and pulseaudio) have a buffer? I think it can't be rhythmbox..even after I 'kill' rhythmbox I get 15 seconds of audio..

I'll try a few more things and report back.

 

[phofman]

What is your full ecasound command?

 

[CharlieLaub]

What is your full ecasound command?

I think he posted that, above.

@Gordon C. - please put CODE and /CODE tags (enclose these in square brackets) around any OS commands or code that you put in your posts. The editor will do this for you if you highlight the text and then click on the "#" icon just above the entry area. That way the forum software won't convert part of the code into emoticons!

Let's see... here are some questions for you:

• What hardware are you using?
• I believe if ecasound finds that it cannot process the audio quickly enough it will automatically increase the buffering (internal buffering), sometimes by a lot. You might be able to override this by using these ecasound commands:

  -z:nointbuf -z:nodb

  The above commands should be put at or near the beginning of the ecasound command string and disable double buffering and internal buffering. Instead of a long delay ecasound might just crash or give error messages, but then at least you would have some hints about the cause.
• If your source material is of different format and some resampling needs to be done along the way this can create a lot of CPU overhead, depending on how the resampling is done. To compensate the system (somewhere) might be inserting buffering that causes the delay.
• If you are streaming the audio in across your LAN there may be some additional latency that is applied.
• Is the large delay (15 sec) consistent by track, e.g. you can play one track and every time there is normal playback e.g. no excessive delay and then if you play another track there is always the 15 sec delay, or is the long delay coming at random.
• Does it happen right from the start, or only after using the system for some time.
• Does the delay ever go from 15sec back down again, or only from no delay to 15 sec, and then it stays there.
• Try to check the CPU and memory usage while ecasound is running, under both normal operation and when there is the large delay. This might illuminate the source of the problem.

Anyway, let us know what you discover.

 

[Gordon C]

aha! I removed all the useful stuff out of the crossover to see if that made a difference. From the sample above I changed it to:

ecasound -d:2 -n:testcrossover \
-B:rt -z:mixmode,sum -f:16,2,44100 \
-a:pre -i:alsahw,2,1,0 -o:loop,1 \
-a:testoutput -i:loop,1 -chorder:1,2,1,2,1,2 -o:alsa

and gave it a try (at low volume) the delay was gone! So Ecasound was the cause of the delay, but I didn't know what to do next, then I saw Charlie's post above and tried again with the "-z:nointbuf" included..

ecasound -d:2 -n:3way-20Hzhighpass-bassshelf \
-B:rt -z:mixmode,sum -z:nointbuf -f:16,2,44100 \
-a:pre,subs -i:alsahw,2,1,0 \
-a:pre -el:RTlr4hipass,100 -o:loop,1 \
-a:mids,tweeters -i:loop,1 \
-a:subs -el:RTlr4lowpass,100 -el:RTlr4hipass,20 -el:RTlowshelf,2,50,0.71 -chorder:0,0,0,0,1,2 \
-a:mids -el:RTlr4lowpass,2000 -chorder:0,0,1,2,0,0 \
-a:tweeters -el:RTlr4hipass,2000 -chorder:1,2,0,0,0,0 \
-a:tweeters,mids,subs -f:16,6,44100 -o:loop,2 \
-a:delay -i:loop,2 -el:mTAP,1.9,1.9,0,0,0,0 -o:alsa

Again, the delay is gone! Video is now watchable again (a movie with a 15sec audio delay is not much fun). You made my day..

I'm going to try a few things on the weekend to see at what point the crossover complexity causes the delay (if it works that way at all). I'll report back..

thank you!

Gordon

 

[phofman]

Well done, guys. Congrats.