Re: Errors from driver
Re: Errors from driver
- Subject: Re: Errors from driver
- From: Mark Cookson <email@hidden>
- Date: Mon, 01 Nov 2004 15:14:29 -0500
Ah, thanks for the info.
We're trying to signal applications of errors, like DMA underrun/overruns,
clock loss, etc., that would be of interest to pro applications. It seemed
like a convenient place to return the error, but I suppose we'll need to
work out something else (we already have user clients and such).
I'm not sure it's worthy of filing a bug report if no one else is looking
for anything like this, but if you think others would benefit, I'll file an
enhancement request.
Mark
On 11/1/04 4:05 PM, "Jeff Moore" <email@hidden> wrote:
> The HAL uses the return value from the kernel trap only to signify
> whether or not it needs to resynchronize. Other than that, the error
> goes off into the ether since there is no mechanism in the HAL to
> report it to an interested client.
>
> If you are trying to debug something in your driver, you can use the
> telemetry in HALLab to see the error being returned to the HAL. It will
> show up as one of the data points to the telemetry event that marks the
> return from the kernel trap.
>
> If you really are trying to say something to a client of the HAL, then
> we'd need to put a new mechanism in the HAL to make it work. In such
> case, feel free to file a feature request.
>
> On Nov 1, 2004, at 11:49 AM, Mark Cookson wrote:
>
>> How do errors return from the driver's
>> clipOutputSamples()/convertInputSamples() routines get returned to the
>> application? It doesn't look like the IOProc takes an error
>> parameter. Do
>> you register a notification (property listener) for this error? If
>> so, what
>> property do you register for?
>>
>> Thanks,
>> Mark
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden