Re: Using MidiMan Delta 66 drivers
Re: Using MidiMan Delta 66 drivers
- Subject: Re: Using MidiMan Delta 66 drivers
- From: "Stephan" <email@hidden>
- Date: Thu, 13 Dec 2001 09:30:39 +0100
- Organization: MIDIMAN
I assume the problem is related to the fact that we have to set the
samplerate to the new value for all (each stereo & multichannel) ports which
are exposed by the Delta driver (only common samplerate for all ports is
allowed on the hardware). This setting takes rather long (see Daisy test
app). Might be that the samplerate setting is still in progress while you
try to start the device thus preventing it from proper restart. I'll have a
look at it, maybe there's a way to avoid the samplerate set request.
Stephan Kappertz
M Audio Germany
----- Original Message -----
>
Date: Wed, 12 Dec 2001 15:02:51 +0100
>
Subject: Using MidiMan Delta 66 drivers.
>
From: Markus Handell <email@hidden>
>
To: email@hidden
>
>
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