Re: User-land driver plugin and sample rate
Re: User-land driver plugin and sample rate
- Subject: Re: User-land driver plugin and sample rate
- From: Stéphane Letz <email@hidden>
- Date: Mon, 3 Nov 2008 14:29:51 +0100
On Oct 31, 2008, at 2:23 AM, Stéphane Letz wrote:
Our user-land driver plugin does not behave correctly when used the
RealPlayer: if RealPlayer plays a wav file, everything works
correctly but the sound get pitched down when RealPlayer plays an
mp3 file.
Is this true for all sample rates (if that's something you can test)?
Yes, but i have some more info: it actually depends of the files:
- some aiff files succeed and some other fail..., but the actual code
that is used to play them if not the same (by tracing the list of
calls that are done to the driver). It seems that the case that works
is using some QuickTime routine.
- when it fails (some aiff of mp3) the sound is playing on one channel
only and seems to be pitched down one octave.
One thing you might want to look at is what properties the app is
asking your driver for and what values are being returned, just to be
sure that they are always consistent with one another.
The application tries to set the kAudioDevicePropertyNominalSampleRate
property (actually using the value the is effectively used), and our
driver accepts that.
Our driver plugin does support a single sample rate, so we implement
a subclass of HP_Stream that does:
<code snipped for bevity>
I presume that kJackStreamFormat is indicating something reasonable
like native endian floating point samples.
#define kJackStreamFormat kAudioFormatFlagsNativeFloatPacked |
kLinearPCMFormatFlagIsNonInterleaved
Otherwise, I don't see anything wrong with that code. It is basically
the same sort of thing the HAL does for IOAudio-based devices.
I see now that HP_Stream class also has a
"TellHardwareToSetPhysicalFormat" method that returns "true" by
default. Should we redefined to return "false" in our plugin?
Sorry. There aren't any comments to help you out with that. I just
updated the file.
At any rate, that method does what it's name says and returns true if
the format change took effect immediately and false if the change will
take place asynchronously.
Since your driver has only one format, this method probably won't get
called. So the fact that it returns true all the time is probably
fine.
It there any other important method that should be adapted for a
"single sample rate" supporting plugin?
I'd be sure that the value for the nominal sample rate properties your
driver returns are matching up with the format properties. But
otherwise, I can't see what you are doing that would be messing up
Real Player in that way.
One thing you might want to try is to build a version of the
AudioReflector driver from our SDK such that it's stream layout and
formats all looked like your device. This would let you test whether
this is a problem with what your driver is doing or if it's a problem
with Real Player. The catch is that the AudioReflector driver doesn't
send the data to a speaker. The way to use it would be to set Real
Player to output to the AudioReflector and use another app to record
the input data from the AudioReflector. Then you can look at the
results in the file to see what you got.
Ok.
Best Regards
Stephane Letz _______________________________________________
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