[Portaudio] Fwd: Re: OSX 10.6. problem

[Ross Bencina]

Hi Dmitry

>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.

Ross.




----- 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


  Hi guys!

  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?

  Dmitry.

  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
    control, though!

    bjorn




------------------------------------------------------------------------------


  _______________________________________________
  Portaudio mailing list
  Portaudio at music.columbia.edu
  http://music.columbia.edu/mailman/listinfo/portaudio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://music.columbia.edu/pipermail/portaudio/attachments/20091201/9387ac70/attachment.html