Subject: Re: [ecasound] Track synching/ segfault on -b:256 problem
From: Kai Vehmanen (k@eca.cx)
Date: Fri Dec 01 2000 - 03:40:16 EET
On Thu, 30 Nov 2000, Lewis Hoffman wrote:
> ecasound -r -a:1 -i t1.wav -o /dev/dsp -a:2 -i t2.wav -o /dev/dsp
Btw; this is risky as /dev/dsp is opened three times: one time for input,
and two times for output. With most drivers, this doesn't work at all. So
it's better to let ecasound do the mixing:
ecasound -r -a:1 -i t1.wav -a:2 -i t2.wav -a:1,2 -o /dev/dsp
>> ecasound -r -a:2 -i t1.wav -o /dev/dsp -a:1 -i /dev/dsp -o t2.wav
> the two track are out of synch. a buffersize of 2048 at 44100Hz is
> about 1/20th of a second, which is probably plenty to explain what i'm
> hearing. I've tried using different buffersize, and -b:512 does seem
Ok, there's something definitely wrong here. Just a few days ago I did
extensive testing with the latest ecasound version and could do multitrack
recording even with really big buffersizes.
> for it to be satisfactorily tight. however, When I set it at 256 or
> below, I get segfaults (on the second command- the first seems to work
> ok). I pasted some stuff from the terminal & gdb down below.
Hmm, this might be driver related. The buffersize specified with -b:x is
used to initialize OSS fragment size.
> I also know that my sound card/driver does not support SNDCTL_DSP_SETTRIGGER,
> and I seem to remember having gotten warnings about that from ecasound,
Ah, this is a problem. SETTRIGGER is used to start the output. This way
ecasound knows the exact time when you start hearing the monitor
track. This information is used in synchronization. The aim is that the
first bytes written to the output files were recorded at the same exact
time when you heard the first bytes of the monitor track. Without
the use of SETTRIGGER, ecasound won't know when the playback has started,
and thus is unable to synchronize recording&playback. From OSS
programmer's guide:
--cut--
Normal operation when writing to the device
[...]
* Starts filling the first buffer fragment with the data written by
the application.
* If enough data was written to fill the first fragment completely,
the device is started to play it.
--cut--
> although i'm not seeing them now. I thought that might have been a
> problem, and I asked on the mailing list for the driver. The author said:
[...]
>> SNDCTL_DSP_SETTRIGGER is IMHO used to enable/disable playback &
>> recording on the same card, by means of opening/closing a second DMA
>> channel.
>> Since the sam9407 doesn't have DMA, there's little meaning behind that
>> call, and we can just as well get along with the O_RDONLY, O_WRONLY
>> or O_RDWR flags used when opening the device.
>> Please correct me, if I miss something here.
Here's what SETTRIGGER should do (from the OSS PG):
--cut--
The SNDCTL_DSP_SETTRIGGER ioctl call has been designed to be used in
applications which require starting recording and/or playback with
precise timing. Before you use this ioctl, you should check that
DSP_CAP_TRIGGER feature is supported by the device. Trying to use this
ioctl with a device not supporting it will give undefined results.
[...]
To actually activate the operation, call SNDCTL_DSP_TRIGGER with the
appropriate bits set. This will start the enabled operations
immediately (provided that there is already data in the output
buffer). It is also possible to leave one of the directions disabled
while starting the another one.
--cut--
Feel free to forward my comments to the author.
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Fri Dec 01 2000 - 05:08:57 EET