Re: Re: An apology about the mass subscription to media-api list - and the reasons why .....

Enrico Weigelt wrote:

>>http://www.ordinateur-dj.org/overview.html
> 
> hmm, somethings to mention:
> 
> 1. we should not enforce threading - in many situations select()-loops
>    perform much better (also many systems dont have MT)

Is there any multimedia system with plugins that doesn't use threads ? 
That sounds very strange (and inefficient) to me. What kind of system 
doesn't have multithreads ?

> 2. GUI should not belong into the same process - better several 
>    processes (okay, that goes OT for media-api)

That was not my idea (actually the system should work without a GUI).

> 3. We should not limit to one fixed internal encoding/resolution. 
>    Better let all devices tell their supported formats and additional
>    metric information for them.

Yeah, I chose this to make it easier to handle. And as it's audio-only. 
If video is used that's more complicated.

For the resolution that's done to reduce the amount of CPU needed from 
the start (after the time stretch) when processing data (final 
resolution). But for better sound quality, the resolution could be 
higher (with faster CPUs and better sources).

> 4. How should speed modification work together w/ timestamps ? 
>    Are they also stretched ? How does the buffer management work then ?

The time-stretcher handles the timestamp tweaking to fit the output. 
Also the timestamp is in samples (IIRC). Coupled with a sampling freq it 
could be converted to time when muxed with video... IMO that's much 
better to keep samples for audio and frames for video along the process.

> Some Ideas we should think about:
> 
> 1. We have several kinds of devices. Some have only output, some only input.
>    (thats not really correct, since they all do IO, but its not always
>    in the scope of the api, but in the scope of the OS)
>    
> 2. Latency of devices can vary. Each device must be able to tell the world,
>    how much latency it has on some specific rate and encoding.

I agree.

> 3. How could we implement frame skipping (like mplayer's -framedrop) ?

Could be a plugin that also tweak timestamps.

> 4. How to handle seeking ?

I think I described it in the ODJ page. It's done from the source 
"filter" and goes downstream as new data are processed. (using messages)