[Portaudio] Fwd: Re: OSX 10.6. problem
rossb-lists at audiomulch.com
Tue Dec 1 06:48:03 EST 2009
>What about my small fixes for x64 platform for Windows compile for WMME and DirectSound? Will they be put to SVN?
I plan to review all the stuff I'm supposed to check in tomorrow. I'll get back to you then.
----- Original Message -----
From: Dmitry Kostjuchenko
To: portaudio at music.columbia.edu
Sent: Tuesday, December 01, 2009 9:08 PM
Subject: [Portaudio] Fwd: Re: OSX 10.6. problem
I have seen that you worked hard on Mac core part :)
I got several comments and thoughts over implementation and issue of changing global Sample Rate at all.
1. Do we acquire device in exclusive mode? What will happen if any other application or say another PortAudio stream changes sample rate to something else again. I mean, if one PortAudio stream expects its sample rate be fixed at say 48000 and is working, while another 2-nd stream tries to change sample rate to 44100 for example (Or user changes through Control Panel). What will happen to 1-st stream, will it be getting 48000 or will start getting 44100 samples per second? Won't we need then AudioDeviceAddPropertyListener to trace global sample rate changes and take actions to avoid corrrupt sound or crash on bad buffer size?
2. New AudioDeviceSetPropertyNowAndWaitForChange: Pa_Sleep( 100 ) - 1 msec waiting is just fine for CPU and make this function be a little more responsive. Sleeping 10 times in loop with 100msec will take 1 second! It is too much.
What about my small fixes for x64 platform for Windows compile for WMME and DirectSound? Will they be put to SVN?
Quoting Bjorn Roche <bjorn at xowave.com>:
Okay, I've implemented this with a dead-simple busy-wait (which
eventually times out). I did this because my original implementation
was wrong and to make it right would have required testing under
behavior that just doesn't seem to come up anymore: it used to be that
waiting for a property to acknowledge a change took a while, whereas
now /setting/ the property seems to take time instead. Maybe this was
apple's way of getting around the issue of too many property
changes... anyway, the point is that correct fix would have been too
hard to test, so this is a bit of a kludge, but it's not too bad.
On my system it took about 5 seconds for the sample rate of the
external hardware to change, which seems... insane. I don't think was
the case when I originally wrote this code (on 10.4?). I find it
pretty obnoxious because in addition to kinda freezing things up, it
also reset the volume on my device to full blast! I thought I must be
doing things wrong, but I get pretty much the same behavior in Audio
MIDI setup (spinning pinwheel while waiting for change) and my system
resets the volume to full blast all the time (bug in my hardware?) so
I think this is correct, actually. Built-in output works as expected.
Much faster. I am testing on 10.5, so YMMV, but I think it will work
on 10.6. The code is much simpler now. You can use patest_sine_srate.c
to check things out, if you like: keep your hand on that volume
Portaudio mailing list
Portaudio at music.columbia.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Portaudio