[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] Re: c39844: server: Assume requested SR was successfully set
On 6.Oct 2015, at 3:46 , Frank Carver <scott@xxxxxxxxxxxxx> wrote:
> Let me look / maybe send you a build with some more logging?
a patch? sure - but would take a while, gotta crash now (4am here).
> This was an issue I was a little afraid of - if your device does not report the sample rate you requested as a viable sample rate, then you won't be able to set it. If we instead DON'T filter sample rate suggestions based on the list reported by the driver, then your case would probably work, but someone else would be able to set 96khz on a device that doesn't support it, and would then get incorrect audio - so there's a trade off.
so far I'm sort of happy to finally know what's going on.
That's been bugging me for weeks (and had very little time to track it down)
> This is all because sample rate changes are asynchronous, and you can't know that a change was successful until you receive a message some time later from the driver. Until the sc server boot sequence is refactored to be asynchronous and multithreaded (not a trivial change), I think we may be stuck with either being conservative about sample rates (only reported options) or allowing anything at risk of subtle or unsubtle audio errors.
not so subtle … alas.
Anyway - it seems it's the internal audio interface.
Just checked my MOTU and it works just fine (flicks SRs as intended).
I just wonder that's just me stumbling upon this.
If the don't-set-SR method is a stable workaround, I can live with that for a while, but it smells funny.
gn8! m.
> On Mon, Oct 5, 2015 at 6:13 PM Michael Zacherl <sdiy-mz01@xxxxxxxxxxxxx> wrote:
>
> On 6.Oct 2015, at 1:05 , Frank Carver <scott@xxxxxxxxxxxxx> wrote:
>
>> I believe the only reason you wouldn't be able to set the sample rate to 96000hz (with that error) is if either one or both the input or output devices don't support it. It looks like you're using the internal in/out devices of a mac (and not an external audio interface)? Can you double-check that 96khz is listed as an option for both the in and out devices in Audio MIDI Setup?
>
> <Screen Shot 2015-10-06 at 2.53.54 .png>
> <Screen Shot 2015-10-06 at 2.52.34 .png>
>
>> And - can you confirm that older builds of SC give you the correct input and output audio when you set the device to 96khz (nothing e.g. pitched down or pitched up?).
>
> the only way _I found_ (not saying that's the only way at all) to get wrong pitches is to deliberately set the SR @ Audio/MIDI setup other than 96k and evaluate my code in a sc-version prior to this patch.
> With this patch I'm getting
>
> Faust: supercollider.cpp: sc_api_version = 2
> Faust: FaustGreyholeRaw numControls=7
> Faust: supercollider.cpp: sc_api_version = 2
> Faust: FaustJPverbRaw numControls=11
> Found 0 LADSPA plugins
> Number of Devices: 5
> 0 : "Built-in Microph"
> 1 : "Built-in Input"
> 2 : "Built-in Output"
> 3 : "Soundflower (2ch)"
> 4 : "Soundflower (64ch)"
>
> RESULT = 0
> ### ERROR: SERVER DID NOT BOOT PROPERLY!
>
> after which I evaluate again which returns the described 88k2 SR behaviour.
>
>> If you're using a build before this bugfix, you'll probably have to restart the server at least once to ensure the correct sample rate is set.
>
> Yes, not on a regular basis, but yes, it is/was glitchy. But at least I could get the 96k in the last two years.
> The only way to get 96k (I just had a hunch yesterday) is to not set s.options.sampleRate (remaining nil),
> which then puts the SR set in Audio/MIDI prefs into action.
--
http://mz.klingt.org
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/