Re: [ecasound] Ecaplayer-RTprio-Volumecontrol-Buffer

Hello,

On Mon, 12 Feb 2007, Klaus Schulz wrote:

> I am new to the list. Though I am using ecasound for a couple of weeks
> now. And I am very happy with it.

that's always nice to hear! :)

> ecasound -r:80 -b:2 -B:rtlowlatency -i:alsahw,1,0 -ea:50 -o:alsahw,1,0

Buffersize of 2 (sample frames) is _really_ low. In most cases I recommend
using at least 16/32 frames. Often the underlying hardware is not able to
support smaller framesizes (for instance limits set by transfers over PCI
bus). Many (if not most) PCI sound cards (like my Delta44) have a lower
limit of 64 bytes for DMA transfers. So with 2ch16bit audio this equals to
buffersize of -b:16. Any values that go beyond the HW limit don't anymore
improve latency, but instead waste useful CPU time into processing
overhead.

> Questions to understand the whole subject a bit better:
>
> 1.a The rt-priority is not shown when using "ps -C ecasound -o rtprio".
> How do I know if I run realtime at what parameter?
> Other programs using rtpriority clearly show this with above command!
> (I am running it as root of course.)

You'll need to print out the scheduling policy with (the priorities are
separate for each scheduling domain). When ecasound uses real-time
scheduling, the policy is SCHED_FIFO. For example:

sh> ps -ma -o pid,tid,class,rtprio,comm

The process marked with "FF" is the SCHED_FIFO thread (i.e. the ecasound
engine thread).

> 1.b Are actually Alsa, the soundcard driver and other process that might
> be in the chain working in realtime?
> How do I make sure that this is the case?

Yes, the engine thread (which runs under SCHED_FIFO) handles all
communication with soundcard hardware.

> 2. With buffersize of two samples I can run ecasound without xruns on my
> PC. I am wondering if I can trust this buffer setting I am using.
> Alsa seems to complain that the buffersize doesn't match the period size ( I read that the period size is supposed to be 1/4th
> of the buffer size) I could not find a paramter to set the period size of alsa within ecasound.
> This low buffer size is giving me best sound results!

I think you are hitting the low limits of your soundcard HW (and/or PCI
bus) here (see above).

> 3.a. Volumecontrol: A scale in db would be helpful, and it should be
> called attentuation insted of amplification!
> What is strange though: I need to get the parameter as low as 15 to 20% for running acceptable volume levels in my setup, running at sound levels of 95db or so.
> Any explanations would be helpful.

The amplify controls in ecasound are linear multipliers. Many have asked
for logarithmic variants, so they should definitely be added at some
point. But for now you need to convert from logarithmic to linear scale in
your head.

> 3.b. With e.g. Samplitude I am running -12--20db to have a similar
> level. What algorithm is behind ecasound scale?

It's linear (100% equaling multiplier of 1.0), so -ea:50 is equivalent to
-6dB, -ea:200 to 6db, -ea:25 to -12dB, -ea:12.5 to -18dB and so forth.

> 3.c. I assume that you do 32bit float volume control with the DSP. Will
> the result be downsized to 16bit before sent to te output?
> Is there a chance to dither the signal?

Unfortunately the signal is not dithered. As a workaround, you can work
with 32bit files, and create the final 16bit master with some program that
does dithering. If you have a soundcard that only supports 8/16bit
samples, you can route the audio via JACK (which again supports 32->16bit
dithering).

Of course, it'd be nice to have dithering as part of ecasound. I have a
todo-list item for taking a look at integrating support for libgdither [1]
to ecasound.

Even better is if dithering is added to libsndfile (which would benefit
many other apps as well).

[1] http://plugin.org.uk/libgdither/
[2] http://www.mega-nerd.com/libsndfile/

> 4. Buffering of tracks: I am buffering all tracks on /tmp (tmpfs) in RAM
> before playing back, that improves the sound heavily.
> Is there an option to do full track buffering with ecasound?

You really shouldn't have to do that. Ecasound provides a disk i/o
subsystem that applies a lot buffering for non-realtime objects (like
files, pipes and network sources) in order to guarantee smooth operation
of the real-time audio engine. This has been extensively tested,
so it is not likely (although not impossible) that disk i/o is
causing quality problems. Double-buffering is on by default (-z:db), but
can be disabled explicitly with '-z:nodb'. See the manpages for more
information.

Ecasound never does full track buffering as the files can be multiple
gigabytes in size (and dealing with files of this size has been one key
design principle)

So if you do get errors without use of /tmp, that would suggest you have
potentially problems elsewhere.

> Where would I have to start to build myself an extended "ecaplayer"
> using existing valubale APIs. (I am not very experienced in programming
> yet!)

Links to most of the developer resources are at:
- http://eca.cx/ecasound/developer.php

-- 
  links, my public keys, etc at http://eca.cx/kv
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list