 |
 |
|
Emuxki driver for SB Live! Audigy and Audigy2 |
|
|
|
|
|
|
| OSS ? |
|
|
By brian21 - Posted on March 15, 2008 - 14:57:35 (#22577)
Current version when comment was posted: 20050203 |
|
|
A quick question about oss driver. When I type osstest in the terminal with media server closed the sound is perfect from my speakers. But when I play music through cl amp or soundplay with media server open there is static/crackling. Whats the deal? Is there a setting I need to change?
|
|
| Awesome |
|
|
By brian21 - Posted on March 11, 2008 - 17:29:28 (#22565)
Current version when comment was posted: 20050203 |
|
|
This is the first time Ive had working sound in beos. Big thanks to Francois. Why does oss not have its on page on bebits?
|
|
| RE: SB0400 Working using OSS |
|
|
By tonestone57 - Posted on January 8, 2008 - 14:28:15 (#22373)
Current version when comment was posted: 20050203 |
|
|
Great to hear it worked for you.
OSS will allow many ( unsupported ) sound cards to work in BeOS & Haiku.
You can try to increase the buffer size & that might get rid of the 50ms pauses every 4 seconds.
Look for the file; "oss_core" in:
~/config/setting/kernel/drivers
Remove # & change dma_buffsize to 64, 96 or 128 from 0.
Hopefully that fixes it. I believe CL-AMP uses more buffering by default. You can also go into VLC & try to set up more buffers. But first I'd try the above & see if that works for you.
|
|
| SB0400 Working in BeOS using OSS |
|
|
By Harold1066 - Posted on January 8, 2008 - 00:49:17 (#22370)
Current version when comment was posted: 20050203 |
|
|
Thanks for the advice on OSS. I followed the instructions below and it works right out of the box. There is a small problem with the audio. About every 4 seconds there are about 50ms holes in the audio. This occurs with all formats .avi .flv .mp3 and .wav files. vlc and media player both do this. CL Amp (BeOS Winamp) plays .wav and .mp3 files perfectly with no audio dropouts. The sound card shows up correctly in Media preferences with all the usual level controls working for playback.
http://revolf.free.fr/beos/oss-beos-v4.1test-bin.zip
unzip oss-beos-v4.1test-bin.zip -d /boot
rescan oss_core
osstest (This line is optional)
Make sure you quit media_server and media_addon_server first, they might be using the card.
Harold
|
|
| RE: SB0400 - Found the Linux Driver Source |
|
|
By tonestone57 - Posted on January 6, 2008 - 23:14:40 (#22364)
Current version when comment was posted: 20050203 |
|
|
That driver is written to work with the Linux kernel. It would have to be updated/changed to work with the BeOS kernel by a programer.
The easiest & quickest option is to change out to a supported sound card. But first you can try OSS to see if it works.
An OSS port is being worked on for BeOS & Haiku. Open source OSS will support your sound card. But this port is not complete yet, still you can test it out & maybe it'll do the trick.
For more information refer to:
http://mailman.opensound.com/pipermail/oss-devel/2007-June/000028.html
For list of supported sound cards, refer to:
http://manuals.opensound.com/devlists/Linux.html
To download & test BeOS early version:
http://revolf.free.fr/beos/oss-beos-v4.1test-bin.zip
|
|
| SB0400 - Found the Linux Driver Source |
|
|
By Harold1066 - Posted on January 6, 2008 - 17:46:26 (#22363)
Current version when comment was posted: 20050203 |
|
|
Update.
Downloaded alsa-driver-1.0.15 from alsa-project.org
Unbz2 and untar it.
Explored around the folders.
Searched inside the entire set of files looking inside the files for SB0400,
Found 2 files
emu10k1.c
emu10k1_main.c
emu10k1.c has the following in it near the beginning
static struct pci_device_id snd_emu10k1_ids[] = {
{ 0x1102, 0x0002, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, /* EMU10K1 */
{ 0x1102, 0x0004, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1 }, /* Audigy */
{ 0x1102, 0x0008, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1 }, /* Audigy 2 Value SB0400 */
{ 0, }
It had to be there because my Linux Ubuntu 7.10 works with the SB0400.
Now comes the question of how to use this info to make a BeOS driver for the Creative Audigy2 Value (SB0400).
Does anyone know how to do the compiling properly?
Harold
|
|
| RE: Audigy 2 - ID 4 works - ID 8 doesn't |
|
|
By Harold1066 - Posted on January 6, 2008 - 11:47:01 (#22361)
Current version when comment was posted: 20050203 |
|
|
A quick update.
Invoking lscpi -v -n in Linux gave the info below
00:0b.0 0401: 1102:0008
Subsystem: 1102:1001
Flags: bus master, medium devsel, latency 32, IRQ 10
I/O ports at b800 [size=64]
Capabilities: [dc] Power Management version 2
lspci
00:0b.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value
Harold
|
|
| RE: Audigy 2 - ID 4 works - ID 8 doesn't |
|
|
By tonestone57 - Posted on January 6, 2008 - 09:17:46 (#22360)
Current version when comment was posted: 20050203 |
|
|
Harold1066 wrote:
Creative
CA0108-IAT
Your sound chipset is the one off the Creative chip.
Your sound card chipset is: CA0108. Which is unsupported in BeOS, Zeta & Haiku.
If you go back to:
http://www.alsa-project.org/main/index.php/Matrix:Vendor-Creative_Labs
And search for CA0108. You'll see it matches the:
Sound Blaster Audigy2 ZS Value. This is your card.
Not sure why they put ZS in the name.
Only way to get sound is to use a supported sound card chipset. emu10k1 or emu10k2 if you want to stick with SoundBlaster. Very important: Check the Creative sound card chip to make sure it is one of these if you go buy another one.
Supported SB IDs are 0002 & 0004 ( click them to see what cards are listed ):
http://pci-ids.ucw.cz/iii/?i=1102
SB uses different chipsets on their lower end/cost cards yet still call them SB Live, Audigy or Audigy2.
|
|
| RE: Audigy 2 - ID 4 works - ID 8 doesn't |
|
|
By Harold1066 - Posted on January 6, 2008 - 02:50:58 (#22359)
Current version when comment was posted: 20050203 |
|
|
Invoking lspci in Linux gets me the following info.
00:0b.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value
The driver in Linux device manager is listed as
info.linux.driver EMUK10K1_Audigy
Opening up the computer and looking at the video card gets me the following info.
Creative
CA0108-IAT
Philips
1361T
(96kHz sampling 24-bit stereo audio ADC)
Datasheet available online
Cirrus Logic (previously Crystal Semiconductor)
CS4382-KQZ
(8 channel D/A)
Datasheet online
Sigmatel
STAT9750
(2 channel AC'97 CODEC with headphone drive and SPDIP output)
Datasheet online
I did look for EMUK10K1_Audigy at http://www.alsa-project.org but could not find it.
I had previously found an interesting technical site at
http://kxproject.lugosoft.com/docs.php?language=en
More research is needed.
Harold1066
|
|
| RE: Audigy 2 - ID 4 works - ID 8 doesn't |
|
|
By tonestone57 - Posted on January 5, 2008 - 10:48:43 (#22357)
Current version when comment was posted: 20050203 |
|
|
Very sure the chipset is different & unsupported.
This driver supports emu10k1 & emu10k2 chipset sound cards. If yours had this then it would only require changing the device id in the driver to recognize your card.
But, your sound card will have either the CA0106 or CA0108 chipset which is unsupported by this driver. And there is no BeOS/Haiku driver for these chipsets.
You can confirm the chipset by pulling out your sound card & looking at the biggest chips on it which will have printed chipset info on them. Or load up Linux & find out which sound card driver is loaded and then figure out which chipset(s) are supported by that driver.
Look here to give an idea of your sound card chipset:
http://www.alsa-project.org/main/index.php/Matrix:Vendor-Creative_Labs
Here is my reply to someone else on Haiku Forums with card id of 7.
http://haiku-os.org/community/forum/haiku_drivers_for_beos_bone_zeta
|
|
| Re: Audigy 2 - ID 4 works - ID 8 doesn't |
|
|
By korli - Posted on January 5, 2008 - 08:12:38 (#22356)
Current version when comment was posted: 20050203 |
|
|
Please check the revision with lspci on Linux.
revision 4 is Audigy 2 and is supported.
revision 8 is Audigy 2 Value and is not supported as of now.
If you know how, you can build the current version of the driver from the Haiku repository, and try if it works for you (TARGET_PLATFORM r5 or dano)
|
|
| Audigy 2 - ID 4 works - ID 8 doesn't |
|
|
By Harold1066 - Posted on January 4, 2008 - 23:17:55 (#22355)
Current version when comment was posted: 20050203 |
|
|
Other owners of Audigy 2 cards say that deviceid 4 works and deviceid 8 does not.
I guess ID 4 is [B400] SB0400 and ID 8 is [B800].
My card ID is 8, Creative Labs (0x1102)
Creative SB Audigy 2 (WDM) [B800].
BeOS 5.03
I have a tripple boot system with Windows 2000, Ubuntu Linux and BeOS 5.03 using the BeOS BootMan. The audio card works perfectly with all OS's but not with BeOS.
BeOS reports my hardware correctly but after correctly installing the driver, there is no recognition by BeOS.
Is the chipset the same for deviceid 8 and deviceid4? If it is the same then what change needs to be made to the driver to accept ID 8. Any suggestions would be welcome. Please respond be leaving a talkback message. I will be checking back often. Thanks.
Harold1066
|
|
| Audigy 2 ZS Platinum Pro |
|
|
By dukzcry - Posted on January 4, 2007 - 07:33:54 (#21155)
Current version when comment was posted: 20050203 |
|
|
It's have an ugly bug... It's playing correctly, but with shout noises (how in Merzbow tracks), so it isn't possible listen it. I tried it with soundcard's output and box's output, the same
|
|
| Got Sound in Paradise |
|
|
By avizan - Posted on May 7, 2006 - 12:27:21 (#19675)
Current version when comment was posted: 20050203 |
|
|
Got sound using old Emu10K drivers. Emuxli SB Live drivers produce sound but with crackle and distortion.
|
|
| May Day in the Virgin Islands No Sound SB Live (CT4870)!!! |
|
|
By avizan - Posted on May 7, 2006 - 07:17:17 (#19673)
Current version when comment was posted: 20050203 |
|
|
I have a Sound Blaster Live Value (CT4870) sound card. I am using Zeta Neo SP1. I have a Biostar M7NCG 400 motherboard. I have disabled the integrated ACH97 sound . Still there is no sound coming from the SB Live card. When I enable the onboard ACH97 sound it shows up along with the SB Live Card in the Media Settings screen. I wouldn't mind using the onbaord sound except that it does not support recording. What a mess.
I have installed Haiku Multi Audio Addon and the Haiku Mixer 0.4. Is there any way to get my Live! to use either emuxki driver or the old emu10k driver? I've installed the emuxki driver from bebits, and it shows up in the Media preferences.
How do I get the Sound Blaster Live (CT4870) to work or to get recording to work in ACH97? avizan@gmail.com
|
|
| Tested with SVN multi audio addon |
|
|
By Cyan - Posted on May 6, 2006 - 11:20:37 (#19672)
Current version when comment was posted: 20050203 |
|
|
After compiling the latest multi audio addon from SVN, the latest emuxki driver now works; problem solved.
I tested the new driver with sample rates of 44.1kHz, 48kHz, and buffer sizes of 32, 64, and 512 frames. All frame sizes work properly on this machine. 44.1kHz isn't usable due to the drifting timer, but 48kHz works fine.
I haven't had a chance to test recording or MIDI yet, as I usually use the hacked driver (to obtain crackle-free 44.1kHz).
|
|
| multiaudio addon from SVN |
|
|
By korli - Posted on May 6, 2006 - 05:57:46 (#19669)
Current version when comment was posted: 20050203 |
|
|
Cyan, please test with the multiaudio addon from SVN.
For debug messages, have a look to the syslog (/var/log/syslog, you have to enable it in kernel settings)
|
|
| Initialization, re-tested |
|
|
By Cyan - Posted on May 5, 2006 - 19:37:21 (#19666)
Current version when comment was posted: 20050203 |
|
|
A follow up to my previous message; I've now re-tested the Haiku emuxki driver, linking the binary into dev/audio/hmulti/ instead of dev/audio/multi/
The same problem still occurs -- the device isn't listed in Media Preferences, and re-installing the old (Jan.2006) driver and restarting Media Services doesn't bring it back (a coldboot is required).
I tested this using the latest binary Multi Audio Addon on BeBits.
Do I need to use the latest Multi Audio Addon from the Haiku source instead? This binary version seemed to work okay with the Jan.2006 driver...
With the latest driver, if I look inside /dev/audio/hmulti in Terminal, I see "emuxki/1" listed. Typing "cat /dev/audio/hmulti/emuxki/1" displays "I/O Error".
I re-installed the Jan.2006 driver (which works okay with my card), and repeated the same process. Inside "/dev/audio/multi" I see "emuxki/1". Typing "cat /dev/audio/multi/emuxki/1" displays "General OS Error".
This is different to the above, suggesting that something different is happening...
The only other thing that comes to mind is the process I used to compile the driver. I inserted the C files into a project file (configured to build a driver), and linked it against the kernel. This process worked fine with the Jan.2006 driver, but do I need to do anything different with the latest version?
Is there any way I can view driver messages during initialization, without attaching a device to the serial port?
|
|
| Interpolation ROM, timer, hmulti |
|
|
By Cyan - Posted on May 4, 2006 - 18:34:20 (#19658)
Current version when comment was posted: 20050203 |
|
|
// check the dev entries : they are now dev/audio/hmulti/
Ah, so I need to re-link the binary into an "hmulti" directory?
That probably explains why it wasn't working here; I'll re-test later tonight...
// Yeah I noticed a problem with 44100 too (not before you
// noticed). I would be interested to see how other OS
// drivers do for this.
On the hacked drivers, I programmed the timer after each interrupt, by looking at the current "play position", and calculating how many frames are remaining.
This constant re-adjustment seems to fix the problem, since it can't slip out of sync over time.
// About the interpolation ROM filter, I think it is rate
// dependant: I would be interested to know which values
// are best for which rates.
As far as I know, 0 is used for rates 0Hz - ~58kHz (58 not 48), and values 1 - 7 should be used for rates ~58kHz (ROM=1) - 192kHz (ROM=7).
The "interpolation ROM" seems to act like a brick-wall low-pass filter. The idea being to remove all frequencies above 24kHz (nyquist) before resampling to 48kHz to avoid aliasing.
When playing back at equal to or less than 48KHz, no filtering is required; the chip can interpolate between samples directly.
For basic audio output (as opposed to "wavetable synthesis"), interpolation filters greater than 0 shouldn't be necessary; the sample rate will always be equal to or less than 48kHz.
|
|
| Cyan |
|
|
By korli - Posted on May 4, 2006 - 13:54:48 (#19652)
Current version when comment was posted: 20050203 |
|
|
Emuxki is working here with Audigy2 (with multiaudio addon from SVN). Be sure to check the dev entries : they are now dev/audio/hmulti/...
Yeah I noticed a problem with 44100 too (not before you noticed). I would be interested to see how other OS drivers do for this.
About the interpolation ROM filter, I think it is rate dependant: I would be interested to know which values are best for which rates.
About record buffer sizes, it's hard to know why it behaves differently : one thing though, record buffers shouldn't be very small, if you want reliability (not loose data, ie because of a PCI bus overload). Recording isn't dependent on the timer so it's not a problem here.
|
|
| Initialization problems? |
|
|
By Cyan - Posted on April 28, 2006 - 16:48:10 (#19607)
Current version when comment was posted: 20050203 |
|
|
I tried downloading, compiling and installing the new emuxki driver today, but it doesn't seem to work for me.
I'm not sure if I did something wrong in the build process, but the driver doesn't appear to complete initialization; during rebooting I hear a click from the soundcard, but it doesn't show up in Media Preferences at all. Re-installing the hacked drivers and restarting Media Services isn't enough to bring it back -- a system coldboot is required before the card responds again, perhaps suggesting some registers are getting set that the card dislikes?
This is with a first-revision SB Live on a Via KT133A chipset, on a Beta Media Kit + BONE R5 system. I could try and debug things if you can give me some pointers about how to approach that...
In any case, I had a look at the new code, and I'm a bit puzzled how 44100Hz is supported? As far as I can see, the 24kHz timer is only programmed upon voice start-up, so surely it'll slip out of sync when running at 44.1kHz because there are a non-integer number of timer clocks per audio buffer? This is the problem I had with the Jan.2006 drivers, which I worked around by programming the timer in the ISR...
The other thing I wondered was the setting of the interpolation ROM (lowpass anti-aliasing filter) -- line 380 of emuxki.c. This is 0x1 in both the Jan.2006 and the Apr.2006 drivers -- is there a reason behind this? The chip documentation seems to suggest that a value of 0 should be used unless the sample rate is greater than ~55KHz.
I set this to zero in the hacked drivers, but it's hard to do a proper listening test because of the time taken to restart Media Services. Sounds like it may be a bit clearer at 0.
Regarding the recording buffer size, the only reason I set it to 512 frames was because it broke when I set it lower. I'm not sure why, but Soundrecorder locks up, and nothing can read from the input.
If this is now fixed, then I see no problem with having the input buffer size follow the output buffer size; in fact it'd be better that way, since low latency recording is then possible...
|
|
| Cyan |
|
|
By korli - Posted on April 28, 2006 - 07:01:52 (#19601)
Current version when comment was posted: 20050203 |
|
|
Maybe you haven't noticed my changes in the Haiku tree:
there is now a driver config file with several values including buffer size, sample rate, bits per sample, buffer count, channel count per stream. I also changed the interrupt handler return value.
I could introduce two buffer size instead of one (playback and record), to match your needs.
Thanks for your interest.
|
|
| New hacked drivers (44.1KHz supported) |
|
|
By Cyan - Posted on April 27, 2006 - 22:03:18 (#19596)
Current version when comment was posted: 20050203 |
|
|
I've been hacking these drivers again; in addition to the previous features (MIDI, 1.3ms latency), this one adds the following features:
- Adjustable sample rate. Can now run at 44.1KHz, and have the E-mu 10k chip perform the resampling. This finally means that the emuxki drivers can be used under plain R5, without any sound quality problems...
Resampling is actually of higher quality than even the beta media kit is capable of, so it may provide a quality improvement for beta media kit / zeta users too.
- Recording now works, even at low latencies. Though this is more of a workaround; a large buffer size (512 frames) is used for recording, while the small buffer (64 frames) is used for playback only.
Four binaries are included, for various combinations of high or low latency (to accomodate slow systems), and for 44.1KHz or 48KHz operation (44.1KHz giving the best quality for music listening).
multi.h can also be hacked and the drivers recompiled to obtain other settings.
Hacked drivers available at:
http://littlebluerodent.tripod.com/hacked_emuxki_driver_v2.htm
The drivers are compiled for BONE+Beta Media Kit; I'm not sure if they'll work under plain R5. Source is included with project file, for recompilcation if necessary.
Again, feel free to integrate any changes into the main source tree; the readme explains how to find the parts I've changed.
I'm not sure if the altered timer code will work properly on an Audigy (it might), but it should provide for slightly more robust operation on an SB Live.
|
|
| Greg |
|
|
By El_Al - Posted on April 18, 2006 - 11:56:52 (#19509)
Current version when comment was posted: 20050203 |
|
|
Version 0.3 is working on my system :o)
Why, just 5 minutes ago I was tinkering on my midi keyboard with the aid of these drivers.
You are right though! KDL came and took me away pretty soon after.
Like I said in an earlier post....Tantalizingly close to a useable midi environment.
Ta
|
|
| To try midi on Audigy |
|
|
By GScrain - Posted on April 13, 2006 - 13:13:48 (#19459)
Current version when comment was posted: 20050203 |
|
|
It is not tested heavily! It may take you to KDL, so save anything important. The interrupts are not enabled on the LiveDrive input, so I think only the midi-out works on that. The Gameport midi was fully working though.
http://mywebpages.comcast.net/gsc70/AudigyInstall3.zip
I am going to work on the Haiku implementation so this will hopefully be obsolete very very soon. Btw, no audio on Audigy2.
|
|
| Greg |
|
|
By El_Al - Posted on April 13, 2006 - 08:05:08 (#19457)
Current version when comment was posted: 20050203 |
|
|
Am I right in assuming you have a working (albeit hackish) midi implementation that you are willing to let me try? If so, I'm asking nicely :o)
Thanks
El_Al
|
|
| Cyan |
|
|
By El_Al - Posted on April 13, 2006 - 07:56:17 (#19456)
Current version when comment was posted: 20050203 |
|
|
Yeah! It's crackly audio as opposed to mangled and I suspect you are right about the MediaKit in R5 being the problem. I have had the emuxki drivers working in Dan0 without issue.
And, yes! the port shows up in Sequitur as /dev/midi/emuxki/1. Reading backward through the posts I see that the Audigy handles the addressing quite differently from the Live so I'm assuming this is why (although it shows up) it doesn't physically work.
Still! useful midi is TANTALIZINGLY close, especially with squeekysynth showing up recently :o)
|
|
| Greg |
|
|
By korli - Posted on April 13, 2006 - 03:45:01 (#19449)
Current version when comment was posted: 20050203 |
|
|
Feel free to customize the mpu401 API. You're welcome!
|
|
| GScrain: generic Haiku mpu401 module |
|
|
By mario - Posted on April 13, 2006 - 00:05:07 (#19444)
Current version when comment was posted: 20050203 |
|
|
Will that work on v.5.0 and the standard (included) SB Live! driver?
|
|
| Midi summary |
|
|
By GScrain - Posted on April 12, 2006 - 20:50:27 (#19441)
Current version when comment was posted: 20050203 |
|
|
Heres the story about midi:
The SBLive has direct addressing of the midi address ports, which works very well with the generic mpu401 module. I am very surprised that Be didn't add the functionality to the driver. The Audigy, and Audigy2 access the midi address ports by indirect addressing which does not work at all with the generic mpu401 module. I have had midi working on the Audigy and have released it to a few people who have asked, but it is bit hackish. So I can either submit the hack code to the Haiku emuxki driver, or add the Audigy workarounds in the generic Haiku mpu401 module.
|
|
| Audigy SE |
|
|
By ljr - Posted on April 12, 2006 - 17:15:57 (#19440)
Current version when comment was posted: 20050203 |
|
|
Any chance to have a audigy SE managed by this driver ?!
I try to add the pciid and set it as audigy (v1) but driver fails. It seems the audigy SE is a bit different than a standard audigy :-(
|
|
| "crackling and dropping" |
|
|
By s_d - Posted on April 12, 2006 - 17:09:08 (#19439)
Current version when comment was posted: 20050203 |
|
|
Sometimes very bad results is evidence of IRQ sharing with network card, or, if there is some intensive USB-traffic - even with USB devices.
|
|
| MIDI, crackle, Live versions |
|
|
By Cyan - Posted on April 12, 2006 - 16:43:10 (#19438)
Current version when comment was posted: 20050203 |
|
|
nutela: I'd imagine that it works with all basic Live versions, though I'm not certain. Make sure the card has both front and rear speaker outputs: The rear outputs have a much better DAC and signal path than the front outputs (which are pretty bad).
El_Al: Not sure why MIDI doesn't work for you; perhaps the Audigy does that differently? Do the ports actually show up in MIDI apps?
As for the crackling problem, depends on the nature of the crackling.
If the audio is sounding harsh and grainy, that's probably because you're using the R5 media kit. The Audigy runs at 48KHz, and the R5 media kit does a bad job of converting 44.1KHz audio to 48KHz.
If it's more severe than that (e.g., audio is mangled), make sure "Real-time Audio" is turned on in the media preferences panel. Or if it is already, try turning it off.
If it still doesn't work, then the buffer size is probably too small. Try increasing it in multi.h, recompile and reinstall. Try 64 first, then 128, 256, 512. The current setting (32) is bleeding-edge and quite demanding, though it certainly makes a mockery of other platforms!
It'd be useful to know what spec your PC is, and what buffer size gives you crackle-free audio.
I'm using a 1.33GHz Athlon with a Via chipset without any sign of crackle (low CPU usage too), but it's possible the Audigy has different requirements? There may also be a problem with the R5 media kit and very low latencies; I've never tested very small buffer sizes on plain R5...
|
|
| Some Success with R5 netserver |
|
|
By El_Al - Posted on April 12, 2006 - 14:02:02 (#19436)
Current version when comment was posted: 20050203 |
|
|
Well I have to say I'm heartened by this! My system is plain netserver R5.0.3 with standard medi kit installed. I was having serious problems getting any of the Haiku drivers to work on top of R5.
I have an early Audigy card installed and had no luck whatsoever with the hacked driver to begin with. Until now, I've been using the Audigy_0.2 pkg by Greg Crain which has basic audio only (no Midi in/out).
A quick compile and make of the hacked sourcecode and a re-install of the multiaudio media add-on got me some sound albeit very crackly.
Don't seem to be getting any midi I/O though :o(
Light at the end of the tunnel though. Definately! Keep up the good work!
El_Al
|
|
| On which Live's does this apply? |
|
|
By nutela - Posted on April 12, 2006 - 09:59:54 (#19434)
Current version when comment was posted: 20050203 |
|
|
I'm buying one of those! Just for fun!
|
|
| Cyan, congratulations |
|
|
By korli - Posted on April 12, 2006 - 03:11:27 (#19433)
Current version when comment was posted: 20050203 |
|
|
great work ! thanks, I'll try to integrate some of your changes.
|
|
| Time to test it! |
|
|
By mario - Posted on April 12, 2006 - 01:49:30 (#19432)
Current version when comment was posted: 20050203 |
|
|
This is superexcellent news, I'll test it as soon as I get home. I only have a vanilla r.5 installation, though.
|
|
| Whoops |
|
|
By Cyan - Posted on April 11, 2006 - 21:34:03 (#19431)
Current version when comment was posted: 20050203 |
|
|
Tripod aren't too fond of remote linking; use the following:
http://littlebluerodent.tripod.com/hacked_emuxki_driver.htm
|
|
| MIDI port, 1.3ms latency |
|
|
By Cyan - Posted on April 11, 2006 - 19:46:38 (#19430)
Current version when comment was posted: 20050203 |
|
|
I should also add that all testing was performed with a Soundblaster Live card, on an R5+BONE+Beta Media Kit system. The card is the very original model; one of the first to come off the production line.
|
|
| MIDI port, 1.3ms latency |
|
|
By Cyan - Posted on April 11, 2006 - 19:37:09 (#19429)
Current version when comment was posted: 20050203 |
|
|
I've enabled MIDI and tested the MIDI I/O: success! Both input and output are working. Input has a 3ms jitter like most other MIDI interface drivers.
Hacked drivers available at:
http://littlebluerodent.tripod.com/hacked_emuxki_driver.zip
(source and R5+BONE+BetaMediaKit binary included, might work on R5?). The readme explains everything, though not always things relating to drivers.
Things I've changed:
- Enabled MIDI I/O
- Decreased buffer size to 32 frames for low latency audio (two buffers, 1.3ms latency)
- Added some code that returns B_INVOKE_SCHEDULER instead of B_HANDLED_INTERRUPT from the interrupt handler under certain conditions; namely when handling MIDI interrupts, and when handling "next audio buffer" interrupts with small buffers. The former seems to remove the 3ms jitter (more detailed testing required), the latter allows use of 32 frames without any crackling at all; previously it crackled at < 64 frame settings.
Rescheduling this frequently probably impacts system performance, but I've not noticed any change in performance yet. The code only reschedules when using small buffers; e.g., only if it's necessary. At the moment a "small buffer" is deemed anything less than 256 frames, but this could probably be lowered to 128 frames (max timeslice is 3ms on BeOS, so it only becomes a real problem below there).
Feel free to add anything from here to the main source tree.
|
|
|
|
|
