Re: [ecasound] problems with cs-set-position

From: Pedro Antonio Fructuoso Merino <pfructuoso@email-addr-hidden>
Date: Mon Aug 08 2005 - 15:51:20 EEST

Kai Vehmanen escribió:

> yes, this is unavoidable due to double-buffering performed by the
> disk i/o subsystem. You can minimize by disabling the double-buffer
> (-z:nodb), but you will increase the risk of xruns.

Now i haven`t "jump" and the time response is minimal. I`m not sure of
the meanig on "xrun", is it a especial type of error? is related with alsa?

> Ok, this sounds a possible bug. There will be some delay between the
> cs-get-position and what is currently played out caused by audio
> device output latency, but this should not be multiple seconds. Do you
> get the
> same results with -z:nodb ...?
Now, with -z:nodb, i can listen better the error: when i make some
successively cs-set-position the real position-time didn`t change but
cs-get-position and ai-get-position gived me a change time position.
Repeat, only happen with a little time jump, e.g., if it`s at the
position 10 and made cs-set-position 100 work fine, the new cs position
and ai position is 100 and the real position-time too, but it it`s at
the position 107 and made cs-set-position 100 i could listen any change
but a cs-get-position and ai-get-position give 100.

> One thing to be careful is mixing ai-set-position and cs-set-position.
> The two can be independently set - i.e. if you set ai-set-position to
> 102, cs-get-position (the chainsetup level position) is unaware of
> this. And also, ai-set-position is not a real-time command (see
> ecasound-iam(1) man
> page for details) which means that the whole engine is stopped and
> restarted
> while performing the command.

i only use cs-set-position.

SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement *
Ecasound-list mailing list
Received on Mon Aug 8 16:15:15 2005

This archive was generated by hypermail 2.1.8 : Mon Aug 08 2005 - 16:15:16 EEST