Re: [ecasound] Samplerate fascism?

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] Samplerate fascism?
From: Kai Vehmanen (kaiv@wakkanet.fi)
Date: Tue Nov 02 1999 - 19:51:14 EET


On Tue, 2 Nov 1999, Jeremy Hall wrote:

> hey that 1/s is important!
[...]
> perhaps a #define to allow broken cards to work. I definitely think a
> warning should be initiated.

Hmm, one possibility is to add a "precise_samplerate_mode=true|false"
to ~/.ecasoundrc ... So:

[p_s_m=enabled]
- ecasound opens a soundcard device and ask for sample rate x
- sound card doesn't support x and suggests y
- sample rate y is used and other parts of ecasound know that device's
  sample rate is y
- data is resampled

[p_s_m=disabled]
- soundcard device is opened and ecasound asks for srate x
- sound card doesn't support x and suggests y
- sample rate y is used, but to other parts of ecasound the device is
  opened with sample rate x
- data isn't resampled
- results depend on abs(x - y)

I guess the default should be 'false' (sb128 would work without
performance loss caused by resampling).

> I also think it might cause underuns, then
> you will be asked to read /usr/lib/oss/docs/README.performance.

Well, if you use ALSA drivers, ecasound already reports about
under/overruns to stderr (ecasound 1.5.11r5 and newer). OSS/Linux
(=commercial) supports this on the driver level (if application caused
over/underruns, a warning message is written to stderr when
application is exited). With OSS/Free this is impossible.

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav


New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2a24 : Tue Nov 02 1999 - 19:44:57 EET