Arve Knudsen <[EMAIL PROTECTED]> writes:This doesn't have to do with PortAudio, frankly. PortAudio does not convert samplerates, it will be constrained by the host device.It looks like you got PortAudio working at least :)Can you verify that the ALSA API is in use, after configuring out OSS
My ALSA card is quite capable of doing 44100
and
JACK? I cannot see why this test should fail, granted your card supports
the given samplerate. If you could be bothered, perhaps you could add
some
debug output to function SetApproximateSampleRate at
pa_linux_alsa/pa_linux_alsa.c: 1575? Ie. you could verify that the
correct
samplerate is indeed passed to ALSA-lib, and that ALSA-lib rejects it.
SetApproximateSampleRate is @ line 1583 in my copy: Making that :
err = snd_pcm_hw_params_set_rate( pcm, hwParams, approx, dir ); printf("%s approx=%lu rate=%d dir=%d\n", __FUNCTION__,approx, err, dir);
return err;
Yields:
[EMAIL PROTECTED]:~/portaudio> bin/patest_sine_formats PortAudio Test: output Signed 16 Bit SetApproximateSampleRate approx=44100 rate=-22 dir=0 Host API: ALSA An error occured while using the portaudio stream Error number: -9997 Error message: Invalid sample rate [EMAIL PROTECTED]:~/portaudio>
Which seems sane. Changing it to:
err = snd_pcm_hw_params_set_rate_near( pcm, hwParams, &approx, &dir ); printf("%s approx=%lu rate=%d dir=%d\n", __FUNCTION__,approx, err, dir);
return err;
Yields:
[EMAIL PROTECTED]:~/portaudio> bin/patest_sine_formats PortAudio Test: output Signed 16 Bit SetApproximateSampleRate approx=48000 rate=0 dir=0 Host API: ALSA Waiting 10 seconds for sound to finish. PortAudio Test Finished: Signed 16 Bit
So perhaps my card does _NOT_ support 44100Hz after all. This is the card as autodetected/configured by SuSE9.0's YaST. Seems there are options to play with including the clock rate but I don't know what I am doing ...
Well if you consider 48000 "near" 44100 ...
PortAudio allows you to test a given configuration, which is not particular to ALSA.You can also look up the PaDeviceInfo struct for any device, to check out the default sample rate. I think the ALSA plughw device will convert the samplerate to a hardware supported one for you, so that might be your best bet?
I think so - googling for 8235 and 44100 shows I am not the 1st to have this kind of problem...
I have
never used the PCM plugin myself, but its possible to specify a custom
device string with pa_linux_alsa. If you look in the pa_linux_alsa.h file,
you'll see a custom stream structure, PaAlsaStreamInfo, which basically
can be used like this:
PaAlsaStreamInfo alsaStreamInfo;
PaStreamParameters outputParameters;
PaAlsa_InitializeStreamInfo(&alsaStreamInfo); alsaStreamInfo.deviceString = "plughw:0,0";
outputParameters.device = paUseHostApiSpecificDeviceSpecification; outputParameters.hostApiSpecificStreamInfo = &alsaStreamInfo;
It's device string will then be used when opening the output device.
But having a custom string then means I need to know that A. PortAudio is using ALSA B. This user's ALSA hw device cannot do my rate
C. Which magic custom string to use.Some devices (software) are not enumerated by ALSA, so there is no way for PortAudio to know.
If I need to know that much I might as well use native ALSA code...The only reason I mentioned plughw is you might want to convert from 44100 to 48000, since your hardware device doesn't support 44k. This is particular to ALSA. Regular hardware devices will be available through PortAudio, requiring no specialized knowledge.
Like I pointed out earlier, PortAudio performs no samplerate conversion (nor will it provide more or less channels than the device supports). The point, as I see it, is cross platform abstraction (with benefits such as buffer adaption and bitdepth conversion). Wether a card supports a specific configuration can be tested, or you can go with the defaults. However, certain API's have their own ways of doing things. ALSA offers software devices, such as plughw, which are not currently enumerated along with the other devices. So in order to use plughw, you will have to pass a custom device string. This requires specialized knowledge in the client app of course, but its the best solution I've come up with. This is getting entirely offtopic though, maybe we best discuss this on the PortAudio list? If you're still interested in the API that is.Surely the whole point of PortAudio is that app says "open sound card for 44100Hz, 16-bit, 2 channels" and the PortAudio layer figures out how to do that?
Regards
Arve Knudsen
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
