PDA

View Full Version : OpenML suitable for low latency audio?



msipkema
06-15-2002, 01:06 AM
Is OpenML suitable for low latency audio io?

The way I read the specification there is no way for an application to use a buffer size that is used by the hardware also, so it won't be possible to do e.g. double buffered io using select() to wait for buffer completion.

cityhunter
06-18-2002, 10:05 PM
question : when such behaviour is required? I find buffer system better since it can hide latency problem (ex : a context switch can prevent your application to output the data at the right time....)

[ June 19, 2002: Message edited by: cityhunter ]

cityhunter
06-18-2002, 10:13 PM
select() seems to be achieved by get wait handle p85 of the spec..... :)

msipkema
06-19-2002, 12:29 AM
<BLOCKQUOTE><font size="1" face="Arial, Verdana, Helvetica, sans-serif">quote:</font><HR>Originally posted by cityhunter:
select() seems to be achieved by get wait handle p85 of the spec..... :)<HR></BLOCKQUOTE>

I read this. I can get a wait handle and then select() on it when buffers are in the reply queue. So when my application is using a double buffereing approach, i.e. sending one buffer and waiting on the other using select(), then sending the other and waiting for the first, how will this work when the hardware is using a much larger buffer? It will be inefficient at the least.

Also, the way OpenML is designed audio buffers will always have to be copied by the driver, right?

If it would be possible to get buffers from the driver (optionally) that would allow the application to work in the hardware's preferred buffer size/number/format and to do mmapped io.

Something more like EASI ( http://www.emagic.de/english/support/easi/ ) , perhaps not using callbacks, but in the way a buffer is described.

With video this is probably less of a problem since the buffer size is always a frame there and most video hardware will be able to read directly from the user allocated memory.

As far as I know most audio hardware read from a fixed buffer in memory, perhaps even contiguous, i.e. they are not able to switch buffer address on buffer completion. And even this would only work if the buffers were the correct size or it would have to support switching buffers at any time. I don't think any audio hardware is designed like that.

msipkema
06-19-2002, 12:39 AM
<BLOCKQUOTE><font size="1" face="Arial, Verdana, Helvetica, sans-serif">quote:</font><HR>Originally posted by cityhunter:
question : when such behaviour is required? I find buffer system better since it can hide latency problem (ex : a context switch can prevent your application to output the data at the right time....)

[ June 19, 2002: Message edited by: cityhunter ]<HR></BLOCKQUOTE>

In a application requiring low latency, the thread(s) for audio io must be high priority (SCHED_FIFO) and thus should only be preempted by higher priority threads.

For a low latency application it is unimportant and it will need large buffers since it doesn't run high priority.

That's why I asked if OpenML is suitable for application demanding low latency audio io. Perhaps OpenML is not meant for it. If it is, I think the API will have to probably be extended.

cityhunter
06-19-2002, 01:59 AM
<BLOCKQUOTE><font size="1" face="Arial, Verdana, Helvetica, sans-serif">quote:</font><HR> Also, the way OpenML is designed audio buffers will always have to be copied by the driver, right? <HR></BLOCKQUOTE>
yes since there no [B]mechanism[\B]to access hardware memory... but this is planned
<BLOCKQUOTE><font size="1" face="Arial, Verdana, Helvetica, sans-serif">quote:</font><HR> With video this is probably less of a problem since the buffer size is always a frame there and most video hardware will be able to read directly from the user allocated memory.<HR></BLOCKQUOTE>
wrong with compressed video.....
<BLOCKQUOTE><font size="1" face="Arial, Verdana, Helvetica, sans-serif">quote:</font><HR> I think the API will have to probably be extended. <HR></BLOCKQUOTE>
yes see my posts on the other forun.... there is a lot of things missing.... and since i've worked on a multimedia api.... that i will abandon if openML change some things.....

there is a way to know the buffer size : see page 73 but i don't find the time period of the audio buffer (T) api...... :roll: