Results 1 to 6 of 6

Thread: OpenML suitable for low latency audio?

  1. #1
    Junior Member
    Join Date
    Jun 2002
    Location
    Delft - Netherlands
    Posts
    9

    OpenML suitable for low latency audio?

    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.
    --ms

  2. #2
    Junior Member
    Join Date
    Jun 2002
    Location
    france, sophia antipolis
    Posts
    19

    Re: OpenML suitable for low latency audio?

    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 ]

  3. #3
    Junior Member
    Join Date
    Jun 2002
    Location
    france, sophia antipolis
    Posts
    19

    Re: OpenML suitable for low latency audio?

    select() seems to be achieved by get wait handle p85 of the spec.....

  4. #4
    Junior Member
    Join Date
    Jun 2002
    Location
    Delft - Netherlands
    Posts
    9

    Re: OpenML suitable for low latency audio?

    <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.
    --ms

  5. #5
    Junior Member
    Join Date
    Jun 2002
    Location
    Delft - Netherlands
    Posts
    9

    Re: OpenML suitable for low latency audio?

    <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.
    --ms

  6. #6
    Junior Member
    Join Date
    Jun 2002
    Location
    france, sophia antipolis
    Posts
    19

    Re: OpenML suitable for low latency audio?

    <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......

Similar Threads

  1. OpenML for Real-Time Video Overlay with Low Latency
    By jrhaws in forum OpenML Coding & Technical Issues
    Replies: 0
    Last Post: 02-15-2008, 05:27 PM
  2. Where is OpenML audio going?
    By msipkema in forum Suggestions for the next OpenML revision
    Replies: 1
    Last Post: 08-01-2003, 07:54 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •