• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Using MidiMan Delta 66 drivers.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Using MidiMan Delta 66 drivers.


  • Subject: Using MidiMan Delta 66 drivers.
  • From: Markus Handell <email@hidden>
  • Date: Wed, 12 Dec 2001 15:02:51 +0100

I'm having some trouble with the Delta 66 on my development system, and I am not sure where the problem lies, in our support for CoreAudio (we use the HAL portion), inside CoreAudio.framework, or in the MidiMan driver.

The thing that happens is that when I change the sample rate, the driver seems to be in a strange state. I think I need to explain what happens.

When we shift the sample rate in our framework, we perform the change with the stream stopped. This is because we use non-interleaved buffers aside from the IOProc-supplied buffers and we don't want to allocate any memory in the IOProc. So we do every change with the sound stream stopped. The thing is, with the Midiman driver chosen, we cannot always start the driver again. The calls fail.

So I fooled around with delays before and after settings changes, and the problem seems to occur less often.

Does anyone know what's going on? I don't like putting sleeps in our software :-) !!!

Thanks,

Markus Handell


  • Follow-Ups:
    • Re: Using MidiMan Delta 66 drivers.
      • From: Jeff Moore <email@hidden>
    • Re: Using MidiMan Delta 66 drivers.
      • From: John Fieber <email@hidden>
  • Prev by Date: Re: time constraint policy and audio proc calls
  • Next by Date: Re: Using MidiMan Delta 66 drivers.
  • Previous by thread: Re: time constraint policy and audio proc calls
  • Next by thread: Re: Using MidiMan Delta 66 drivers.
  • Index(es):
    • Date
    • Thread