wouter1 / emu-driver Goto Github PK

View Code? Open in Web Editor NEW

189.0 189.0 30.0 33.41 MB

OSX Kernel extension for Creative Labs EMU driver

C 3.18% C++ 96.36% Shell 0.46%

emu-driver's People

Contributors

Stargazers

Watchers

emu-driver's Issues

record/playback issues (USB pipe error e00002ef) on some machines

Running on Yosemite appears to fail.

From the logs, the call to Read() in readFrameList is failing with

USB pipe READ error e00002ef

sync input and output

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 error

http://forums.macrumors.com/showthread.php?s=b7d660127f5bbd50631d656f3888c9ae&p=20530636#post20530636

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

4 channels?

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?

restructure audio input code

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:

the framelist bytes must have been gathered (GatherInputSamples got all frames from the list)
the completion callback must have been received (readCompleted was called)

click in playback after 30 seconds play

Sometimes you hear a small click about 30 seconds after starting a playback.

fix software volume

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

attempting to clip to a position more than one buffer ahead of last clip position

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)

checking reaper reported latency

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.

engine sometimes can't be stopped

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.

playback errors input overrun

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

control panel changes only output rate, not input rate

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.

sometimes missing wrap on input?

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

restructure audio output code

I'd like to move all audio output stream related code to the USBOutputStream class that I created already

test/acceptance procedure

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.

test Audio MIDI Setup app

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.

Output stutter when multiple applications using driver

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

stuttering just before start and right after playback of sound

after changing volume the playback stutters for about 10 seconds.

support other sample rates

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.

byte-accurate sync input and output

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.

enable audio playback

Maybe we can also fix the playback

midi issues

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.

phase inversion

TomDrinkwater reported that the phase is being reversed in a roundtrip test connecting output directly to input.

perform audio test for driver

In #40 an input latency issue was fixed. We now need to re-test the audio quality

EMU 0404 does not start

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?

latency too high

There seems much more latency than expected.

low latency script deletes text in plist?

A user reported that the low latency script deletes all text in the plist.

fix code to suggest alternative setting

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

make compatible with original control panel

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.

lower latency

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

midi support

It is not known if the driver supports midi

Sound assertion "0 == thisUnitIDNum" failed

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

get extension sign code

It would be nice if we could sign our code, so that people can avoid putting the machine in kext-dev-mode

unplanned commits

There seem to be unplanned commits on the kext. These commits are not tested and should not be there.

cleanup USBAudioObject

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.

driver version number

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 abort there are STILL 126 active TDs

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

HAL bundle?

In old versions of this extension, there was a HAL bundle

Do we need this?

support 192kHz sample rate?

The EMU0404 supports much higher rates than the current max of 96kHz

Can we support those on OSX?

96kHz not working second time

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

restructure project to allow other documents in the workspace

We need to restructure the workspace here, so that we can add documentation and other components

raised noise level on main out if no headphone attached

It seems that the noise level on the main output is lower if a headphone is attached.

Reduce debug output for master release

Current kext is built with debug options on. Seems good idea to build a release for the master branch.

hf noise in output at 176 and 196kHz

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:

document build instructions

We need to add build instructions to the readme

remove syncer?

The mSyncer is deprecated by Apple. Maybe we can find a different way to do this

Inputstream proceed to next framelist before completion of current

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.

distortion from audacity

A weird distortion occurs in the following situation.

Set EMU to 192kHz
Open audacity and set project rate to 192k and select EMU for in and out
Sample some sound
Play back the sound to confirm it's ok
Switch audacity project rate to 96kHz (but don't switch the EMU)
play back the sound. It now sounds distorted

Found with commit 18368ac

hangup hardwareMuteChangedHandler and VolumeChangeHandler

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.

sampling at wrong rate

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.

wouter1 / emu-driver Goto Github PK

emu-driver's People

Contributors

Stargazers

Watchers

Forkers

emu-driver's Issues

Recommend Projects

Recommend Topics

Recommend Org