kxproject / kx-audio-driver

kX driver source code (for Windows and Mac)
Other
141 stars 64 forks source link

OSX/Mavericks: Streams crackling after short period of time #5

Closed herrnst closed 10 years ago

herrnst commented 10 years ago

(prequel: I apologize if this is the wrong area to post issues regarding the (OSX)driver)

Hello,

am using the OSX driver to run a SB0350 (Audigy 2 ZS, emu10k2) on Mavericks (10.9.2) on a Sandybridge hack. The driver causes a quite annoying issue (which definitely isn't there on Win and Linux, and wasn't there at least on OSX Lion):

Whenever audio is played back, after a random but usually short amount of time (from one minute up to ten minutes, seems it can be amplified by putting load on the system) the audio stream starts crackling, sounding as if some kind of buffer would be either shifted or overrun, but the original sound is still noticeable (so it doesn't just start to make random noise). Stopping and starting the stream again (e.g. in iTunes, hit stop and start) fixes it temporarily until it starts to make buffer-shifting sounds again. Only stereo speakers are connected, Audio/MIDI setup is configured for stereo mode aswell. Aside from this, audio playback works very well and stable.

Honestly I don't know anything about all things kernel, driver and/or CoreAudio related on OSX, but I'm able (and willing!) to build the driver from the sources and can of course test things.

Again, I apologize if this is the wrong place to post issues.

kxproject commented 10 years ago

Hello,

I'm sorry, but we currently cannot work on this driver, so, I suggest you try to re-build the driver from sources (available here at github), and check if re-compiled version gives you any improvements. If not, then, perhaps, there needs to be some Mavericks-specific fix, or some better synchronization/timestamp code. If you could find a OSX programmer interested in fixing the bug, I'd be happy to merge the fix into our codebase.

vladkorotnev commented 10 years ago

I had the same problem and it appears to be the sample rate dropping for some reason. When this occurs in Logic, a warning message appears saying that the device tried to forcibly change the sample rate to 0Hz, 5Hz, 15Hz, 5kHz, 15kHz (sequential multiple messages).

~ Vladislav Korotnev http://vladkorotnev.github.io/ http://vladkorotnev.me akasaka@nopan.eu vladkorotnev@orenoimoutogakonnanikawaiiwake.gan.ai vladkorotnev@gmail.com 2:5020/12000.64

On 13 May 2014, at 3:12 , Daniel Scheller notifications@github.com wrote:

(prequel: I apologize if this is the wrong area to post issues regarding the (OSX)driver)

Hello,

am using the OSX driver to run a SB0350 (Audigy 2 ZS, emu10k2) on Mavericks (10.9.2) on a Sandybridge hack. The driver causes a quite annoying issue (which definitely isn't there on Win and Linux, and wasn't there at least on OSX Lion):

Whenever audio is played back, after a random but usually short amount of time (from one minute up to ten minutes, seems it can be amplified by putting load on the system) the audio stream starts crackling, sounding as if some kind of buffer would be either shifted or overrun, but the original sound is still noticeable (so it doesn't just start to make random noise). Stopping and starting the stream again (e.g. in iTunes, hit stop and start) fixes it temporarily until it starts to make buffer-shifting sounds again. Only stereo speakers are connected, Audio/MIDI setup is configured for stereo mode aswell. Aside from this, audio playback works very well and stable.

Honestly I don't know anything about all things kernel, driver and/or CoreAudio related on OSX, but I'm able (and willing!) to build the driver from the sources and can of course test things.

Again, I apologize if this is the wrong place to post issues.

— Reply to this email directly or view it on GitHub.

herrnst commented 10 years ago

@kxproject Thanks for the response! I'm already running a binary built from Git HEAD (which builds fine with Xcode5+ btw if you fix it up so it doesn't try to build for 32bit anymore ;) ). Unfortunately, I don't know anyone who runs a Hack or MacPro and additionally has an E-mu10kx card in the same box.

Guess the issue might has something to do with the new Timer Coalescing thing introduced with Mavericks (also ran the driver on ML, besides some clicks and pops it ran without issues) so it doesn't get the needed attention when it should, thus causing something going out of sync. Looked at the sources a bit already and "think" I found some spots where simple changes (e.g. larger buffers) might help. If something works out, I'll of course send one or more PRs against the project :)

herrnst commented 10 years ago

@kxproject I've increased the buffer size which is used to allocate the streams in CoreAudio in kXAudioEngine::initHardware() by a factor of 4 in the ::init() method, see https://github.com/herrnst/kx-audio-driver/commit/aa1a4d6ee2302de4d0e30375c28a73bcfffc9c20. With this very simple change, any playing stream won't start crackling anymore if some timers or so in OSX become inaccurate. Further down in the execution path, the value gets respected in the ongoing initialisation:

kernel[0]: kXAudioEngine[0xffffff8019d8d800]::init - n_frames=8192
kernel[0]: kXAudioEngine[0xffffff8019d8d800]::initHardware(0xffffff80184d4400)
kernel[0]: kXAudioDevice [HAL] asio: allocating voices 0,1; latency: -8192 -- 32-bit
kernel[0]: kXAudioDevice [HAL] asio: alloc_output(chn=2; hw=0)
...

Latency-wise, I don't see any regression, looks like this just gets compensated by the audio subsystem. So while I can't tell if anything needs to be adjusted in regards to the initialisation of "hw->mtr_buffer.size", this currently seems to completely fix the issue for me, but of course this needs some more days of testing.

If you're interested, I can add a bit of code that detects the OSX/kernel version and increase buffers only if Mavericks is detected (never experienced the problem with ML or even earlier versions), and create a pull request out of this.

kxproject commented 10 years ago

I think we could merge the change into the driver code without specific test for Mavericks. Note that playback buffer size influences 'recording' buffer size, which is limited by 65536 bytes. So, this change might impact recording code in the future (when someone wants to finish it).

herrnst commented 10 years ago

@kxproject created https://github.com/kxproject/kx-audio-driver/pull/7 for this. Guess when (and if, that is) someone will finish up the things he or she should probably also take a more thorough look at it. However, with the increased buffer, I never experienced the problem again in the last days, without touching anything else system-related.

wujekbogdan commented 9 years ago

Thanks @herrnst , I'm surprised that somebody still cares about ancient Audigy 2 in 2014 :) I've compiled kext file and it seems to work fine.

herrnst commented 9 years ago

Glad it helps some more people (felt quite being the last one using an audigy card, but as even in '14 motherboard codecs still sound thin and "muffled" compared to the Audigy, I'd rather keep it). Would be nice to know what's up with Yosemite regarding the driver, didn't try myself yet.

wujekbogdan commented 9 years ago

Funny, I thought I'm the last one :) I've been using KX drivers since the first beta release of Yosemite. Everything used to work fine (the same as under 10.9.x). Now on stable 10.10 is sill works. I didn't try microphone yet, so I can't confirm is it OK or not.

PS I have no idea is it related to your fix, or is it just a coincidence, but after installing the fixed kext I can finally use google hangout. Previously the hardware was recognized properly but there was no sound at all. I had to use onboard sound card for Hangout. The same about google translate. It was strange because Hangout and Google Translate were the only applications affected by this bug.

ForbiddenEra commented 9 years ago

I'm still interested in using this card, especially since I may be putting OS X on my Poweredge 2950 (dual quadcore xeon 3ghz w/ 16gb ram) using one of my Audigys.

I've been using my S4 a lot more than the Audigy partially due to the aforementioned problem. I will take a look at the fix. If I have some time, I am very interested in further developing this driver and getting it working good.

I agree with @herrnst, the audigy 2 (any version) blows out a lot of newer cards unless they're strictly professional, and even then, a lot aren't that great or are orientated towards DJing or something.

owenjbrady commented 9 years ago

@herrnst how do I apply this patch? do I just add it into the list do I have to somehow recompile it? I am a windows/linux user new to mac would really like to get this card stable in OS X 10.10 but I am a noob with these mac drivers.... is there anyway you can just zip me yours? much appreciated.

wujekbogdan commented 9 years ago

I have already done it. Here you can download compiled kext: http://hamac.pl/topic/10045-audigy-2-poprawiony-sterownik-kx/ btw, compiling can't be easier. there's a .xcodeproj directory committed to the repository, so all you have to do is to import the project to xcode and find compilation options in the menus :)

// edit: Then you have to copy the .kext file to the /System/Library/Extensions directory and set chmod -R 755 and chown -R root:wheel. Or you could use a tool like KextWizard or similar.

owenjbrady commented 9 years ago

@wujekbogdan thank you so much really mean that!

mr-pug commented 8 years ago

When I compile this with Xcode 7.1, I'm not only seeing the kext, but also a support library: libFloatLib.a. Doesn't that also need to be copied somewhere?

wujekbogdan commented 8 years ago

No. All you need is the .kext file.