wouter1 / emu-driver Goto Github PK
View Code? Open in Web Editor NEWOSX Kernel extension for Creative Labs EMU driver
OSX Kernel extension for Creative Labs EMU driver
Running on Yosemite appears to fail.
From the logs, the call to Read() in readFrameList is failing with
USB pipe READ error e00002ef
see also #17 and http://forums.macrumors.com/showthread.php?s=b7d660127f5bbd50631d656f3888c9ae&p=20530636#post20530636
The question how to sync input and output within an engine is fundamental and may be behind a number of current issues.
The main question is: we have 1 AudioEngine that supports both input and output.
"A major responsibility of your IOAudioEngine subclass is to take a timestamp each time the I/O engine loops from the end of THE sample buffer to the beginning of the sample buffer. " (quote from the Apple documentation on writing audio drivers, my emphasis). Now, we have TWO sample buffers, which one is THE sample buffer?
Note, properly this is not a ticket for us as we don't write the core system audio. However the question is relevant as it may underly some of the issues we have.
Installer gives error
(kernel) Kext com.emu.driver.EMUUSBAudio not found for unload request.
Failed to unload com.emu.driver.EMUUSBAudio - (libkern/kext) not found.
deleting old kext
moving things
doing permissions stuff
loading new kext
Requesting load of /System/Library/Extensions/EMUUSBAudio.kext.
/System/Library/Extensions/EMUUSBAudio.kext failed to load - (libkern/kext) not loadable (reason unspecified); check the system/kernel logs for errors or try kextutil(8).
Can't stat /Users/bencarlin/symbols/ - No such file or directory.
so long
logout
In #10 it was noticed that some of the EMU interfaces offer 4 channel input and output.
What are these 2 extra channels? Can we use them?
The current audio input code was coded in the same style as the original code from sourceforge.
That is, all required code is inside the large EMUUSBAudioEngine.
It would be much better if this code could be pulled into the ADRingBuffer class (which was already made but the restructure did not yet materialize). The name ADRingBuffer was picked instead of something like InputRingBuffer because it is only input for the client; for the driver it's also an output buffer.
The USB input stream maybe can be moved to yet another class to keep it separate from the AD ring buffer.
The code around the locking is tricky. It would be nice if this can be done in a cleaner way that link properly to the two requirements for re-use of a USB framelist:
Sometimes you hear a small click about 30 seconds after starting a playback.
The software volume (eg, using the volume slider in OSX) is not working. EMU seems always at max volume regardless where you put the slider..
Sometimes I see this
Jan 26 20:40:16 vlieland kernel[0]: IOAudioStream[0xffffff80441d1000]::clipIfNecessary() - Error: attempting to clip to a position more than one buffer ahead of last clip position (54,814)->(55,fd5).
Jan 26 20:40:16 vlieland kernel[0]: IOAudioStream[0xffffff80441d1000]::clipIfNecessary() - adjusting clipped position to (55,814)
(in this case, playing from Audacity with 1ms record latency and 2ms set hard in the code)
A user has given me feedback on the reaper reported latencies.
This presumedly is with the default driver
reaper says:
[44.1kHz 24bit WAV : 2/2ch 64spls ~ 1.4/3.4ms]
44.1Khz 64 samples 1.4/3.4ms I think the 2 figures are input and output latency, and they include the buffer size reported.
I can get figures for different sample rates and buffer sizes if it is helpful. They change as you would expect with the buffer sizes (I think so anyway - I haven’t actually calculated how many samples is 1ms at each rate and worked it out)
I’m not sure why the input latency is less. Different interfaces vary quite a bit in these figures, with the same buffer size settings.
This doesn’t change when I change the plist.
I rebooted after changing it - I presume that reloads it ok? or is there a cache that needs updating?
I also tried unloading and reloading from the terminal using the same commands that are in your install script. It still reports above figures however the plist is set. Since the above figures include the 64 samples reaper buffer I think it is actually using the 2.2ms latency, even when it is set to 4.2ms.
These are very good figures so I have no complaints, but it is strange that it doesn’t change when the plist is changed.
Sometimes the engine keeps running even though there are no more active audio applications.
You can notice because these messages do NOT appear shortly after all audio apps were stopped
Jan 9 12:09:11 vlieland kernel[0]: +EMUUSBAudioEngine[0xffffff803c9c6000]::performAudioEngineStop ()
Jan 9 12:09:11 vlieland kernel[0]: +EMUUSBAudioEngine[0xffffff803c9c6000]::stopUSBStream ()
Jan 9 12:09:11 vlieland kernel[0]: +EMUUSBInputStream::stop
Jan 9 12:09:11 vlieland kernel[0]: EMUUSBOutputStream::stop
Jan 9 12:09:11 vlieland kernel[0]: writeHandler: now stopped 2 of 2
Jan 9 12:09:11 vlieland kernel[0]: writeHandler: now stopped 3 of 2
Jan 9 12:09:11 vlieland kernel[0]: All playback streams stopped
Jan 9 12:09:11 vlieland kernel[0]: +EMUUSBAudioEngine::OurUSBOutputStream::notifyClosed.
Jan 9 12:09:11 vlieland kernel[0]: EMUUSBInputStream::readCompleted all input streams stopped
Jan 9 12:09:11 vlieland kernel[0]: +EMUUSBAudioEngine::OurUSBInputStream::notifyClosed.
Jan 9 12:09:12 vlieland kernel[0]: -EMUUSBAudioEngine[0xffffff803c9c6000]::stopUSBStream ()
Jan 9 12:09:12 vlieland kernel[0]: -EMUUSBAudioEngine[0xffffff803c9c6000]::performAudioEngineStop()
This may be related to my fix for #18 as I can't remember it was there before.
After such fail, turning the EMU off and on does not resolve the problem. The driver keeps in some kind of running mode.
If you are doing playback, you get overrun errors
RingBufferDefault<USBInputRing>::push warning. Ignoring overrun
reproduce ith playback from audacity (but not with Quicktime player).
You can see those also in Sierra, using log stream
in the terminal
If you change the sample rate with the control panel, we only get a performFormatChange call for the output stream. This output format change is called twice.
It seems that this leaves the input channel at a wrong rate (eg, 48kHz while output is at 96kHz). This causes the input stream to behave weird, we get an input stream at 96kHz containing a 48kHz data stream. Half of the 48kHz samples are just duplicated every 96 input samples.
Jan 11 19:20:25 vlieland kernel[0]: WRITE framenr 866013 at 867363448840
Jan 11 19:20:25 vlieland kernel[0]: READ framelist 2 in framenr 866141 at 867363607506
Jan 11 19:20:25 vlieland kernel[0]: WRITE framenr 866077 at 867427413540
Jan 11 19:20:25 vlieland kernel[0]: READ framelist 3 in framenr 866205 at 867427524353
Jan 11 19:20:25 vlieland kernel[0]: write wrap in usbframe 866141 list 2
Jan 11 19:20:25 vlieland kernel[0]: WRITE framenr 866141 at 867491453880
Jan 11 19:20:25 vlieland kernel[0]: READ framelist 0 in framenr 866269 at 867491612683
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866205 at 867555378432
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 1 in framenr 866333 at 867555491087
Jan 11 19:20:26 vlieland kernel[0]: write wrap in usbframe 866269 list 2
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866269 at 867619505380
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 2 in framenr 866397 at 867619648846
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866333 at 867683398679
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 3 in framenr 866461 at 867683494656
Jan 11 19:20:26 vlieland kernel[0]: write wrap in usbframe 866397 list 2
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866397 at 867747511154
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 0 in framenr 866525 at 867747668401
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866461 at 867811503885
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 1 in framenr 866589 at 867811620165
Jan 11 19:20:26 vlieland kernel[0]: write wrap in usbframe 866525 list 2
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866525 at 867875375994
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 2 in framenr 866653 at 867875534675
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866589 at 867939455546
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 3 in framenr 866717 at 867939569080
Jan 11 19:20:26 vlieland kernel[0]: write wrap in usbframe 866653 list 2
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866653 at 868003478474
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 0 in framenr 866781 at 868003618631
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866717 at 868067474687
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 1 in framenr 866845 at 868067575888
Jan 11 19:20:26 vlieland kernel[0]: write wrap in usbframe 866781 list 2
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866781 at 868131513304
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 2 in framenr 866909 at 868131671847
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866845 at 868195521610
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 3 in framenr 866973 at 868195645727
Jan 11 19:20:26 vlieland kernel[0]: write wrap in usbframe 866909 list 2
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866909 at 868259511229
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 0 in framenr 867037 at 868259675654
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 866973 at 868323479656
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 1 in framenr 867101 at 868323596840
Jan 11 19:20:26 vlieland kernel[0]: write wrap in usbframe 867037 list 2
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 867037 at 868387389621
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 2 in framenr 867165 at 868387555852
Jan 11 19:20:26 vlieland kernel[0]: WRITE framenr 867101 at 868451502488
Jan 11 19:20:26 vlieland kernel[0]: READ framelist 3 in framenr 867229 at 868451618551
Jan 11 19:20:27 vlieland kernel[0]: write wrap in usbframe 867165 list 2
Jan 11 19:20:27 vlieland kernel[0]: WRITE framenr 867165 at 868515401226
Jan 11 19:20:27 vlieland kernel[0]: READ framelist 0 in framenr 867293 at 868515557426
Jan 11 19:20:27 vlieland kernel[0]: WRITE framenr 867229 at 868579502929
Jan 11 19:20:27 vlieland kernel[0]: READ framelist 1 in framenr 867357 at 868579617568
Jan 11 19:20:27 vlieland kernel[0]: write wrap in usbframe 867293 list 2
Jan 11 19:20:27 vlieland kernel[0]: WRITE framenr 867293 at 868643490053
Jan 11 19:20:27 vlieland kernel[0]: READ framelist 2 in framenr 867421 at 868643648952
I'd like to move all audio output stream related code to the USBOutputStream class that I created already
I need to design a good test
so far the tests were just sampling a piece of music and then playing it back. Music almost always has small noises where you can't detect any clicking.
There is a Audio MIDI Setup app in System/Applications/Utilities
It allows you to set input and output rates independently.
Need to test this as EMU does not support such independent rates.
It seems that starting up an application can disturb audio output.
Blender seems a good program to cause such issues.
The effect of this is messages like this in the console
Jan 9 17:36:05 vlieland kernel[0]: **** Output Hiccup!! firstSampleFrame=4236, nextExpectedOutputFrame=1152 bufsize=98304
Jan 9 17:36:36 vlieland kernel[0]: **** Output Hiccup!! firstSampleFrame=4428, nextExpectedOutputFrame=1152 bufsize=98304
After that, the driver sometimes recovers, sometimes not
after changing volume the playback stutters for about 10 seconds.
Currently you only get this (in console) when you switch to a non-96kHz sample rate
Nov 21 17:03:54 --- kernel[0]: USB hick (42012263). timer re-syncing.
Nov 21 17:03:55 --- kernel[0]: USB hick (43000245). timer re-syncing.
Nov 21 17:03:55 --- kernel[0]: USB hick (42985110). timer re-syncing.
Nov 21 17:03:55 --- kernel[0]: USB hick (41983101). timer re-syncing.
Would be nice if we can support those too.
Maybe some of the existing issues require even more accurate syncing between input nd output. Previously we syncted down to the USB frame (#30) but maybe this is not good enough.
Let's see how close we really are and if we can get this closer.
Maybe we can also fix the playback
trambouter reported in #18
Wouter1, when i change sample rate in "Audio MIDI Setup app" nothing happens, and sample rate in select box not each time changed.
TomDrinkwater reported that the phase is being reversed in a roundtrip test connecting output directly to input.
In #40 an input latency issue was fixed. We now need to re-test the audio quality
I am sorry for terrible English - I have to use Google Translate.
Today, after turning on the computer, I found that Mac OS X Yosemite does not "see" EMU.
That's part of the system log messages:
3/8/15 10:34:50.000 kernel[0] *** kernel exceeded 500 log message per second limit - remaining messages this second discarded *** 3/8/15 10:34:51.000 kernel[0] +EMUUSBAudioDevice[0xffffff802a012800]::queryXU 3/8/15 10:34:51.000 kernel[0] DigitalIOStatus changed 3/8/15 10:34:51.000 kernel[0] Digital IO SampleRate 3/8/15 10:34:51.000 kernel[0] EMUUSBAudioDevice::deviceRequest result=-536854449 3/8/15 10:34:51.000 kernel[0] unitID 14 3/8/15 10:34:51.000 kernel[0] clearing pipe stall result 0 3/8/15 10:34:51.000 kernel[0] ++EMUUSBAudioDevice[0xffffff802a012800]::deviceRequest(0xffffff811de83d28, 0) = e000404f 3/8/15 10:34:51.000 kernel[0] DigitalIO Sync Lock 3/8/15 10:34:51.000 kernel[0] EMUUSBAudioDevice::deviceRequest result=-536854449 3/8/15 10:34:51.000 kernel[0] clearing pipe stall result 0 3/8/15 10:34:51.000 kernel[0] ++EMUUSBAudioDevice[0xffffff802a012800]::deviceRequest(0xffffff811de83d28, 0) = e000404f 3/8/15 10:34:51.000 kernel[0] -EMUUSBAudioDevice[0xffffff802a012800]::QueryXU
This part of the constantly repeated until the EMU is turned off.
I removed the driver strictly according to your instructions, reinstall it. The same error all the time.
Instal "stock" driver. Without effect.
Because with "stock" driver EMU also does not work, so it is assumed that the problem is not in the drivers, and in my system. Maybe you have any ideas how to solve this problem?
There seems much more latency than expected.
A user reported that the low latency script deletes all text in the plist.
The code in EMUUSBAudioEngine::performFormatChange in newAlternateSettingID = ... is broken. It always will return 255 in a clumsy way.
it's not clear in which condition s we get here
it would be nice if we can make the driver compatible with the original control panel.
As it is now, users have to use the original driver to get the control panel working.
For some users, having low latency round trip with software plugins is important.
Maybe we can do something to get a low latency.
Trambouter reports that Logic Pro report 137ms latency on input with 64samples buffer. See #18
It is not known if the driver supports midi
i see these messages right after turning on the EMU device.
They are hard to spot as they immediately scroll out of the window
Dec 1 19:58:59 vlieland kernel[0]: considerRebuildOfPrelinkedKernel com.aladdin.kext.aksfridge triggered rebuild
Dec 1 19:58:59 vlieland.fritz.box com.apple.kextd[12]: kext com.emu.driver.EMUUSBAudio 100009000 is in exception list, allowing to load
Dec 1 19:58:59 vlieland kernel[0]: Sound assertion "0 == thisUnitIDNum" failed in "/Volumes/prive/git/EMU-driver/src/EMUUSBAudio/EMUUSBAudioDevice.cpp" at line 2072 goto Exit
Dec 1 19:58:59 --- last message repeated 1 time ---
Dec 1 19:58:59 vlieland.fritz.box VDCAssistant[366]: VDCAssistant: Found a camera (0x14500000041e3f04) , but was not able to start it up (0x0 -- (os/kern) successful)
Dec 1 19:58:59 --- last message repeated 1 time ---
Dec 1 19:58:59 vlieland kernel[0]: Sound assertion "0 == thisUnitIDNum" failed in "/Volumes/prive/git/EMU-driver/src/EMUUSBAudio/EMUUSBAudioDevice.cpp" at line 2072 goto Exit
Dec 1 19:58:59 --- last message repeated 6 times ---
Dec 1 19:58:59 vlieland kernel[0]: Sound assertion "0 != result" failed in "/Volumes/prive/git/EMU-driver/src/EMUUSBAudio/EMUUSBAudioDevice.cpp" at line 1375 goto Exit
Dec 1 19:58:59 --- last message repeated 1 time ---
It would be nice if we could sign our code, so that people can avoid putting the machine in kext-dev-mode
There seem to be unplanned commits on the kext. These commits are not tested and should not be there.
Could use better error reporting and less code duplication
Eg use this code once instead of everywhere again
EMUUSBAudioStreamObject* stream = GetStreamObject(interfaceNum, altInterfaceNum);
if (!stream) {
IOLog("Bug? EMUUSBAudioConfigObject::GetEndpointPollInterval stream not opening");
return 1; // can we cancel the whole thing?
}
similar for getting the endpoint.
In About this mac/More Info/System Report/Extensions you can see the EMU driver version number
EMUUSBAudio - 1.4.0 - 02/03/15 21:51- not loaded - not signed
Where is this info set? Can we couple it to git version numbers somehow?
After turning off the EMU device, you get (a.o.) this.
The message 'after abort there are STILL 126 active TDs' seems not ok.
Nov 27 19:18:10 vlieland kernel[0]: +EMUUSBAudioEngine[0xffffff80352f3800]::stopUSBStream ()
Nov 27 19:18:10 vlieland kernel[0]: USBF: 577.186 +AppleUSBXHCI[0xffffff81a8844000]::AbortIsochEP[0xffffff802ceba000] - done - pEP->outSlot (0x58) pEP->inSlot (0x81) activeTDs (126) onToDoList (0) todo (0) deferredTDs (0) deferred(0) scheduledTDs (126) onProducerQ (0) consumer (6233) producer (6233) onReversedList (0) onDoneQueue (0) doneQueue (0)
Nov 27 19:18:10 --- last message repeated 1 time ---
Nov 27 19:18:10 vlieland kernel[0]: USBF: 577.187 +AppleUSBXHCI[0xffffff81a8844000]::AbortIsochEP[0xffffff802ceba000] - done - pEP->outSlot (0x58) pEP->inSlot (0x81) activeTDs (126) onToDoList (0) todo (0) deferredTDs (0) deferred(0) scheduledTDs (126) onProducerQ (0) consumer (6233) producer (6233) onReversedList (0) onDoneQueue (0) doneQueue (0)
Nov 27 19:18:10 vlieland kernel[0]: USBF: 577.187 AppleUSBEHCI::DeleteIsochEP- after abort there are STILL 126 active TDs
Nov 27 19:18:10 vlieland kernel[0]: -EMUUSBAudioEngine[0xffffff80352f3800]::stopUSBStream ()
In old versions of this extension, there was a HAL bundle
Do we need this?
The EMU0404 supports much higher rates than the current max of 96kHz
Can we support those on OSX?
I toggled in the control panel betwen 48 and 96 kHz and now the driver has huge amount of distortion when sampling at 96kHz.
I tried older version of the driver, same problem
We need to restructure the workspace here, so that we can add documentation and other components
It seems that the noise level on the main output is lower if a headphone is attached.
Current kext is built with debug options on. Seems good idea to build a release for the master branch.
TomDrinkwater reported (see #40 )
there is a nasty noise on the output at 192 and 176k sample rates. It is 40dB below full scale, and inaudible (presumably) due to high frequency.
i think it is the output because when I unplug the loopback cable it disappears. I will test some more.
if I normalise it and zoom into see individual samples it looks like this:
We need to add build instructions to the readme
The mSyncer is deprecated by Apple. Maybe we can find a different way to do this
EMUUSBInputStream#GatherInputSamples currently is handling only the currentFrameList.
This gives problems with the latency when callbacks are delayed more than usual. #40
GatherInputSamples needs to look more ahead and proceed to the next framelist even if the current one has not yet completely finished.
A weird distortion occurs in the following situation.
Found with commit 18368ac
I'm getting this error messages with my driver when I start up audacity or the control panel
Dec 18 19:14:04 vlieland kernel[0]: EMUXUCustomControl::addUserClient 0xffffff804ef3f700, 0
Dec 18 19:14:04 vlieland kernel[0]: EMUXUCustomControl::addUserClient 0xffffff804ef3f600, 0
Dec 18 19:14:04 vlieland kernel[0]: new format from INPUT
Dec 18 19:14:04 vlieland kernel[0]: +EMUUSBAudioEngine::performFormatChange existing sampleRate is 96000 direction 1
Dec 18 19:14:04 vlieland kernel[0]: newFormat->fBitDepth 24, newFormat->fNumChannels 2
Dec 18 19:14:04 vlieland kernel[0]: fDriverTag = 0x20007
Dec 18 19:14:04 vlieland kernel[0]: ++about to set input : ourInterfaceNumber = 2 & newAlternateSettingID = 7
Dec 18 19:14:04 vlieland kernel[0]: averageSampleRate = 96000
Dec 18 19:14:04 vlieland kernel[0]: alternateFrameSize is 586
Dec 18 19:14:04 vlieland kernel[0]: EMUUSBAudioEngine::SetSampleRate 96000
Dec 18 19:14:04 vlieland kernel[0]: using SampleRateXU
Dec 18 19:14:04 vlieland kernel[0]: called setNumSampleFramesPerBuffer with 12288
Dec 18 19:14:04 vlieland kernel[0]: newFormat->fNumChannels = 2, newFormat->fBitWidth 24
Dec 18 19:14:04 vlieland kernel[0]: -EMUUSBAudioEngine::performFormatChange, result = 0
Dec 18 19:14:04 vlieland kernel[0]: new format from OUTPUT
Dec 18 19:14:04 vlieland kernel[0]: +EMUUSBAudioEngine::performFormatChange existing sampleRate is 96000 direction 0
Dec 18 19:14:04 vlieland kernel[0]: newFormat->fBitDepth 24, newFormat->fNumChannels 2
Dec 18 19:14:04 vlieland kernel[0]: fDriverTag = 0x10007
Dec 18 19:14:04 vlieland kernel[0]: ++about to set output : ourInterfaceNumber = 1 & newAlternateSettingID = 7
Dec 18 19:14:04 vlieland kernel[0]: alternateFrameSize is 586
Dec 18 19:14:04 vlieland kernel[0]: EMUUSBAudioEngine::SetSampleRate 96000
Dec 18 19:14:04 vlieland kernel[0]: using SampleRateXU
Dec 18 19:14:04 vlieland kernel[0]: called setNumSampleFramesPerBuffer with 12288
Dec 18 19:14:04 vlieland kernel[0]: newFormat->fNumChannels = 2, newFormat->fBitWidth 24
Dec 18 19:14:04 vlieland kernel[0]: -EMUUSBAudioEngine::performFormatChange, result = 0
Dec 18 19:14:04 vlieland kernel[0]: +EMUUSBAudioDevice::hardwareVolumeChangedHandler
Dec 18 19:14:04 vlieland kernel[0]: unitID 14
Dec 18 19:14:04 vlieland kernel[0]: mDigitalIOXU
Dec 18 19:14:04 vlieland kernel[0]: +EMUUSBAudioDevice[0xffffff8048806000]::QueryXU
Dec 18 19:14:04 vlieland kernel[0]: DigitalIOStatus changed
Dec 18 19:14:04 vlieland kernel[0]: Digital IO SampleRate
Dec 18 19:14:04 vlieland kernel[0]: EMUUSBAudioDevice::deviceRequest result=0
Dec 18 19:14:04 vlieland kernel[0]: ++EMUUSBAudioDevice[0xffffff8048806000]::deviceRequest(0xffffff821fd83db0, 0) = 0
Dec 18 19:14:04 vlieland kernel[0]: EMUXUCustomControl::hardwareValueChanged value 0
Dec 18 19:14:04 vlieland kernel[0]: EMUXUCustomControl::hardwareValueChanged result 0
Dec 18 19:14:04 vlieland kernel[0]: DigitalIO Sync Lock
Dec 18 19:14:04 vlieland kernel[0]: EMUUSBAudioDevice::deviceRequest result=0
Dec 18 19:14:04 vlieland kernel[0]: ++EMUUSBAudioDevice[0xffffff8048806000]::deviceRequest(0xffffff821fd83db0, 0) = 0
Dec 18 19:14:04 vlieland kernel[0]: EMUXUCustomControl::hardwareValueChanged value 1
Dec 18 19:14:04 vlieland kernel[0]: EMUXUCustomControl::hardwareValueChanged result 0
Dec 18 19:14:04 vlieland kernel[0]: -EMUUSBAudioDevice[0xffffff8048806000]::QueryXU
Dec 18 19:14:07 vlieland kernel[0]: +EMUUSBAudioDevice::hardwareVolumeChangedHandler
Dec 18 19:14:07 vlieland kernel[0]: +EMUUSBAudioDevice::hardwareMuteChangedHandler
Dec 18 19:14:07 vlieland kernel[0]: EMUUSBAudioDevice::setFeatureUnitSetting sending device request 1
Dec 18 19:14:07 vlieland kernel[0]: USBF: 37.912 AppleUSBXHCI[0xffffff81c1cf3000]::GenerateNextPhysicalSegment - Error generating segments, err: e00002e8, numsegments:1
Dec 18 19:14:07 vlieland kernel[0]: USBF: 37.912 AppleXHCIAsyncEndpoint[0xffffff8047f78800]::Schedule - returned 0xe00002e8
Dec 18 19:14:07 vlieland kernel[0]: USBF: 37.912 AppleUSBXHCI[0xffffff81c1cf3000]::GenerateNextPhysicalSegment - Error generating segments, err: e00002e8, numsegments:1
Dec 18 19:14:07 vlieland kernel[0]: USBF: 37.912 AppleXHCIAsyncEndpoint[0xffffff8047f78800]::Schedule - returned 0xe00002e8
Dec 18 19:14:07 vlieland kernel[0]: USBF: 37.912 AppleUSBXHCI[0xffffff81c1cf3000]::GenerateNextPhysicalSegment - Error generating segments, err: e00002e8, numsegments:1
Dec 18 19:14:07 vlieland kernel[0]: USBF: 37.912 AppleXHCIAsyncEndpoint[0xffffff8047f78800]::Schedule - returned 0xe00002e8
The device seems to hang then, and the app (audacity, control panel) with it.
This happens when you start up the app.
Sometimes the playback seems to go at the wrong speed. Usually when I play back a 440Hz sample tone from Mathematica
one time the speed was roughly doubled, but not exactly. I cxan't remember exactly but I think it was 950 instead of 440. First I thought I havd set the test tone to 1000Hz but I double checked and it was 440. I thought it was a mistake.
Until it hapened again. This time the rate was exactly halved, 220Hz instead of 440, and the sample lasted twice as long as expected, 20 minutes intstead of 10. After this I checked with Audio Midi app. The EMU both input and output was 44100, I think I did change the output from built-in to EMU after Mathematica was opened. Audacity was set with a 96kHz project rate, 2 input channels. Mathematica tone is sampled at 32kHz.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.