Drives
I have several different drives on 3 machines that play music without "crosstalk". Seagate Barracuda is currently the best line for audible quietness and Fujitsu has a comparable now. Actually now that I think of it, I've probably used 8 different pc's or notebook pc's with different drives and can't remember any sounds being generated by file transfer.
It may not be your drive causing the trouble but instead it might be your network interface card or ethernet wiring (I'm assuming you're transfering files in via ethernet, but if not, then use the appropriate logic for the right situation). This would make more sense if the card is sitting next to the soundcard in the pci bus.
If it's emi radiating from cabling or hard drive into the soundcard, then you can shield with grounded aluminum foil and verify that.
Were you playing music when you heard the file transfers or was your soundcard idle? If it was playing, then maybe the noise was the player being interrupted by higher priority file transfers. Just increase the priority of the player.
Finally, perhaps you have a high-impedance input acting like an antenna in your soundcard. Either disable it with whatever control panel you have or terminate it with a groundcap.
-Robert
I have several different drives on 3 machines that play music without "crosstalk". Seagate Barracuda is currently the best line for audible quietness and Fujitsu has a comparable now. Actually now that I think of it, I've probably used 8 different pc's or notebook pc's with different drives and can't remember any sounds being generated by file transfer.
It may not be your drive causing the trouble but instead it might be your network interface card or ethernet wiring (I'm assuming you're transfering files in via ethernet, but if not, then use the appropriate logic for the right situation). This would make more sense if the card is sitting next to the soundcard in the pci bus.
If it's emi radiating from cabling or hard drive into the soundcard, then you can shield with grounded aluminum foil and verify that.
Were you playing music when you heard the file transfers or was your soundcard idle? If it was playing, then maybe the noise was the player being interrupted by higher priority file transfers. Just increase the priority of the player.
Finally, perhaps you have a high-impedance input acting like an antenna in your soundcard. Either disable it with whatever control panel you have or terminate it with a groundcap.
-Robert
USB1.1 device on USB2.0 interface
While thinking about the M-Audio Transit as the usb digital receiver, I am wondering whether 2 or 3 of these devices (for 4 or 6 channels from BruteFIR) will overload the usb? They are usb1.1 devices but they'll be plugged into usb2.0 on new motherboard. I guess the question is can usb1.1 devices share the full bandwidth of usb2.0 or do they cause it to downgrade its capacity?
Any opinion on whether the diy dacs are equal to the dac-1?
-Robert
While thinking about the M-Audio Transit as the usb digital receiver, I am wondering whether 2 or 3 of these devices (for 4 or 6 channels from BruteFIR) will overload the usb? They are usb1.1 devices but they'll be plugged into usb2.0 on new motherboard. I guess the question is can usb1.1 devices share the full bandwidth of usb2.0 or do they cause it to downgrade its capacity?
Any opinion on whether the diy dacs are equal to the dac-1?
-Robert
Re: Re: Re: Music player pc definition
Partly because I'm not sure that a fanless Epia can handle full-duplex I/O and full duplex network streaming simultaneously without problems. It might be able to, in which case the problem is pretty much solved.
The other part is that it makes sense to handle all your 'source' requirements from one pc.
peufeu said:
Partly because I'm not sure that a fanless Epia can handle full-duplex I/O and full duplex network streaming simultaneously without problems. It might be able to, in which case the problem is pretty much solved.
The other part is that it makes sense to handle all your 'source' requirements from one pc.
Re: Rightmark
I'd heard a bit about the EMU cards a while ago before they were actually out, but hadn't been paying attention. From the sounds of things, they are pretty impressive - VERY VERY close to LynxTwo results on RMAA tests, at significantly lower cost. The 1212M is very attractive, as according to an EMU tech guy in one of the forums, the two spdif outputs are independent. This gives 2 high-quality analog channels and 4 digital channels out from a $200 card. The 1820M gives 6 digital and 8 or 10 high-quality analog outs plus a bunch of input options for only $500 - pretty serious bang-for-buck.
It doesn't look like it has quite the same engineering put into the clocks as the Lynx cards, but you have to cut somewhere. No Linux drivers at the moment, though. Still, one of those in a DC-operated Epia running win2k simply to stream audio from the network to the card is pretty attractive.
RFScheer said:
I'd heard a bit about the EMU cards a while ago before they were actually out, but hadn't been paying attention. From the sounds of things, they are pretty impressive - VERY VERY close to LynxTwo results on RMAA tests, at significantly lower cost. The 1212M is very attractive, as according to an EMU tech guy in one of the forums, the two spdif outputs are independent. This gives 2 high-quality analog channels and 4 digital channels out from a $200 card. The 1820M gives 6 digital and 8 or 10 high-quality analog outs plus a bunch of input options for only $500 - pretty serious bang-for-buck.
It doesn't look like it has quite the same engineering put into the clocks as the Lynx cards, but you have to cut somewhere. No Linux drivers at the moment, though. Still, one of those in a DC-operated Epia running win2k simply to stream audio from the network to the card is pretty attractive.
Re: USB1.1 device on USB2.0 interface
I actually had exactly this idea, and I'm still curious as to whether it's feasible. The 'simple' answer is that it won't work - a USB 1.1 device will force a 2.0 bus to drop to the lower signalling speed whenever the v1.1 device is the target of traffic. This means that only one Transit can be on a single bus at a time, since it will eat most of the available bandwidth.
However, I'm still not at all clear as to what the real topology of the USB controllers in modern machines is. Is there really only one bus, or are there multiple independent busses? Even if there is only one on the motherboard, you could add a PCI card for extra busses.
From there, though, you're probably back to the same old problem with multiple soundcards - they'll be running from slightly different clocks, and so will drift relative to each other. I *think* the USB clock is somehow used for the master clock, but if there are multiple busses then there will in general be multiple clocks.
In the special case (if it exists) that an embedded motherboard controller runs multiple independent busses from the same clock, then you might get away with it. With BruteFIR, you'd have to do some ALSA magic to get the multiple devices to look like a single device which isn't flawless, but it should work.
Well, from a purely technical/measurement/engineering perspective, I'd say no chance. The benchmark is a pretty impressive piece of work, and I just don't see a DIY approach being able to get the little details right in terms of layout, grounding, EMI etc to get the DR and THD+N numbers down to the level of the DAC-1.
However, numbers don't tell the whole story, and I don't doubt that there might be some diy efforts out there that you'd find equal to it from a subjective perspective. In particular, if you did the master-clock-in-the-dac approach and slaved the source to it, (pretty easy with a PC) you could get very very low jitter and could couple that with some of the optimized I/V and analog stage approaches that are where some of the DIY approaches can equal/exceed conventional efforts. It really depends on where you want to spend your time/money.....
okay, three posts in a row - I'll stop for a while.....
RFScheer said:
I actually had exactly this idea, and I'm still curious as to whether it's feasible. The 'simple' answer is that it won't work - a USB 1.1 device will force a 2.0 bus to drop to the lower signalling speed whenever the v1.1 device is the target of traffic. This means that only one Transit can be on a single bus at a time, since it will eat most of the available bandwidth.
However, I'm still not at all clear as to what the real topology of the USB controllers in modern machines is. Is there really only one bus, or are there multiple independent busses? Even if there is only one on the motherboard, you could add a PCI card for extra busses.
From there, though, you're probably back to the same old problem with multiple soundcards - they'll be running from slightly different clocks, and so will drift relative to each other. I *think* the USB clock is somehow used for the master clock, but if there are multiple busses then there will in general be multiple clocks.
In the special case (if it exists) that an embedded motherboard controller runs multiple independent busses from the same clock, then you might get away with it. With BruteFIR, you'd have to do some ALSA magic to get the multiple devices to look like a single device which isn't flawless, but it should work.
Well, from a purely technical/measurement/engineering perspective, I'd say no chance. The benchmark is a pretty impressive piece of work, and I just don't see a DIY approach being able to get the little details right in terms of layout, grounding, EMI etc to get the DR and THD+N numbers down to the level of the DAC-1.
However, numbers don't tell the whole story, and I don't doubt that there might be some diy efforts out there that you'd find equal to it from a subjective perspective. In particular, if you did the master-clock-in-the-dac approach and slaved the source to it, (pretty easy with a PC) you could get very very low jitter and could couple that with some of the optimized I/V and analog stage approaches that are where some of the DIY approaches can equal/exceed conventional efforts. It really depends on where you want to spend your time/money.....
okay, three posts in a row - I'll stop for a while.....
Re: Drives
I am running it on a 802.11b card. When I get some time I will have to troubleshoot it a bit more.RFScheer said:
USB1.1 device on USB2.0 interface
My reading on several usb sites tonite indicates you can multiplex many usb1.1 devices operating at 12Mbps on a usb2.0 interface. I don't know what the practical limits are or which motherboards do a good job of this?
But if we're interested in running 2 or 3 M-Audio Transits for 4 or 6 digital channels, one worry appears to be cleared.
Now we just need to figure out whether they can be synch'd together. May just require trying it.
Is this a promising direction?
-Robert
My reading on several usb sites tonite indicates you can multiplex many usb1.1 devices operating at 12Mbps on a usb2.0 interface. I don't know what the practical limits are or which motherboards do a good job of this?
But if we're interested in running 2 or 3 M-Audio Transits for 4 or 6 digital channels, one worry appears to be cleared.
Now we just need to figure out whether they can be synch'd together. May just require trying it.
Is this a promising direction?
-Robert
Re: USB1.1 device on USB2.0 interface
Not really... i think you should forget about USB interfaces.
They maybe be close with syncing, but definatley not bit perfect which is what youll need to achieve your "worlds best" goal.
Not really... i think you should forget about USB interfaces.
They maybe be close with syncing, but definatley not bit perfect which is what youll need to achieve your "worlds best" goal.
Inching closer
The new testbed Linux machine now being assembled. 3rd & 4th channels ready on new amp. BruteFIR test installation completed on old machine.
Nexus 350W power supply w/ 120mm fan (~20dBSPL).
Nexus 120mm case fan (throttled & mounted w/ heat glue).
AthlonXP 2500 w/ Nexus 19dBSPL cooler (throttled).
Gigabyte GA-7S748-L motherboard w/ passive-cooled SIS chipset.
1G PC2700 DDRAM @ 333MHz
Seagate Barracuda 160G
AOpen 16x DVD
Gigabyte FX5200 video (will likely remove fan)
Antec Sonata case
I'll report on ambient sound from completed unit tomorrow.
Ordered 2x M-Audio Transits (usb soundcards) @ $70ea. Will test them for first shot at configuring 4ch BruteFIR crossover. So far reading indicates they may be sufficient for digital outs to dac. Haven't found any indication they are not bit perfect, but we'll see.
Stay tuned.
-Robert
The new testbed Linux machine now being assembled. 3rd & 4th channels ready on new amp. BruteFIR test installation completed on old machine.
Nexus 350W power supply w/ 120mm fan (~20dBSPL).
Nexus 120mm case fan (throttled & mounted w/ heat glue).
AthlonXP 2500 w/ Nexus 19dBSPL cooler (throttled).
Gigabyte GA-7S748-L motherboard w/ passive-cooled SIS chipset.
1G PC2700 DDRAM @ 333MHz
Seagate Barracuda 160G
AOpen 16x DVD
Gigabyte FX5200 video (will likely remove fan)
Antec Sonata case
I'll report on ambient sound from completed unit tomorrow.
Ordered 2x M-Audio Transits (usb soundcards) @ $70ea. Will test them for first shot at configuring 4ch BruteFIR crossover. So far reading indicates they may be sufficient for digital outs to dac. Haven't found any indication they are not bit perfect, but we'll see.
Stay tuned.
-Robert
Re: Inching closer
They will not be bit perfect... no where near infact.
Im 99% sure of it.
I wouldnt be supprised if they were even a few milliseconds out of sync.
RFScheer said:
They will not be bit perfect... no where near infact.
Im 99% sure of it.
I wouldnt be supprised if they were even a few milliseconds out of sync.
Re: Inching closer
You let yourself loose on the specs of that machine !
I just assembled a webserver with lesser specifications (Athlon XP 2000+ and 512Mb DDR400)... and it rocks... my other linux machine can't even benchmark it to saturation !
Don't forget to install a low latency Linux kernel on it.
I advise Gentoo linux (www.gentoo.org) with the gaming kernel sources. Activate low-latency scheduling and preemptible kernel in the kernel config. They are very stable and it's almost impossible to make the audio skip, even with lots of other processes hogging the CPU...
However, good luck with your soundcards. I don't think you'll be able to sync them.
You let yourself loose on the specs of that machine !
I just assembled a webserver with lesser specifications (Athlon XP 2000+ and 512Mb DDR400)... and it rocks... my other linux machine can't even benchmark it to saturation !
Don't forget to install a low latency Linux kernel on it.
I advise Gentoo linux (www.gentoo.org) with the gaming kernel sources. Activate low-latency scheduling and preemptible kernel in the kernel config. They are very stable and it's almost impossible to make the audio skip, even with lots of other processes hogging the CPU...
However, good luck with your soundcards. I don't think you'll be able to sync them.
May have to take the covers off
Libranet up and running. Not low latency though, so will likely check out Gentoo as recommended.
On the soundcards, I'm hoping to be able to clock them both from an external master although this may require taking the covers off and poking around a bit.
-Robert
Libranet up and running. Not low latency though, so will likely check out Gentoo as recommended.
On the soundcards, I'm hoping to be able to clock them both from an external master although this may require taking the covers off and poking around a bit.
-Robert
Re: May have to take the covers off
That wont help.
You will be playing audio to two separate devices... the Linux kernel and ALSA (or JACK) wont make an effort to sync the two.
Even if they did, i think it would still be out of sync due to USB data being transfered in packets.
Getting the internal clock of the "soundcards" sync'ed is the least of your worries.
RFScheer said:
That wont help.
You will be playing audio to two separate devices... the Linux kernel and ALSA (or JACK) wont make an effort to sync the two.
Even if they did, i think it would still be out of sync due to USB data being transfered in packets.
Getting the internal clock of the "soundcards" sync'ed is the least of your worries.
Re: May have to take the covers off
No need to look at a different distro just for a kernel.
Grab the lastest 2.4.xx kernel, get the low latency and other patches for it and compile it yourself.
That way youll also end up with a smaller quicker kernel over the pre compiled (or config'ed) jobbies.
You also might want to look at getting the new version of GCC (3.4.0).
It has a few new optimisations that will help the CPU intensive apps (kernel, brutefir) run that little quicker.
RFScheer said:
No need to look at a different distro just for a kernel.
Grab the lastest 2.4.xx kernel, get the low latency and other patches for it and compile it yourself.
That way youll also end up with a smaller quicker kernel over the pre compiled (or config'ed) jobbies.
You also might want to look at getting the new version of GCC (3.4.0).
It has a few new optimisations that will help the CPU intensive apps (kernel, brutefir) run that little quicker.
Today
Sticking w/ Libranet/Debian for now. New motherboard doing great. Ambient is tolerably low but not silent. Bumping up to 2.6.5 kernel w/ better built-in sound and latency. Downloading now. Will be configuring linux for next day or so.
Also will stick with M-Audio Delta 410 PCI soundcard for testing of BruteFIR. You all convinced me usb is not high probability.
As soon as I'm up on 4 channels with reasonable crossovers, I'll figure out what's next for better dac.
-Robert
Sticking w/ Libranet/Debian for now. New motherboard doing great. Ambient is tolerably low but not silent. Bumping up to 2.6.5 kernel w/ better built-in sound and latency. Downloading now. Will be configuring linux for next day or so.
Also will stick with M-Audio Delta 410 PCI soundcard for testing of BruteFIR. You all convinced me usb is not high probability.
As soon as I'm up on 4 channels with reasonable crossovers, I'll figure out what's next for better dac.
-Robert
Re: Today
What I like with Gentoo is its extreme configurability. You get everything you want, but you can remove anything you don't want. Kind of the opposite of Redhat...
But, I heard a lot of good things about Debian, too. Whatever distro you use, for audio, it is principally the quality of your low latency kernel patches which will determine if it skips or not.
Low latency in audio processing is not necessary, there is no problem in having 500ms of delay between the output of your audio player and your speakers (unless you play movies of course). However a preemptible / low latency kernel will keep the audio from skipping when the machine is loaded, and that matters !
Other things to do to keep your audio smooth :
- Nice X so it doesn't hog the CPU
- Don't use XFS
I use ReiserFS but ext3 is also good for your application.
What I like with Gentoo is its extreme configurability. You get everything you want, but you can remove anything you don't want. Kind of the opposite of Redhat...
But, I heard a lot of good things about Debian, too. Whatever distro you use, for audio, it is principally the quality of your low latency kernel patches which will determine if it skips or not.
Low latency in audio processing is not necessary, there is no problem in having 500ms of delay between the output of your audio player and your speakers (unless you play movies of course). However a preemptible / low latency kernel will keep the audio from skipping when the machine is loaded, and that matters !
Other things to do to keep your audio smooth :
- Nice X so it doesn't hog the CPU
- Don't use XFS
I use ReiserFS but ext3 is also good for your application.
Re: Re: Today
Even better... dont use X windows at all, its not needed for this application.
Also dont use ReiserFS, it has latency issues just like XFS has.
Just use plain ext3.
Also, dont use any of the 2.6.x kernels.
Even with its new "preemptive" workings, it still doesnt cut it for real time audio processing, esp when those apps requires large CPU time (brutefir).
As i said before, use the latest 2.4.xx kernel with Andrew Morton's low-lat patch.
peufeu said:
Even better... dont use X windows at all, its not needed for this application.
Also dont use ReiserFS, it has latency issues just like XFS has.
Just use plain ext3.
Also, dont use any of the 2.6.x kernels.
Even with its new "preemptive" workings, it still doesnt cut it for real time audio processing, esp when those apps requires large CPU time (brutefir).
As i said before, use the latest 2.4.xx kernel with Andrew Morton's low-lat patch.
Re: Re: Re: Today
That's what I use and it works very well.
You still need X to get a nice interface for that media player... or do you want to navigate your music in text mode ? (that's assuming you store your music on HDDs)
No issues with reiserfs... for a music only machine, ext3 is OK but I use the Pc for many other things, and reiserfs is so much better...
That's what I use and it works very well.
You still need X to get a nice interface for that media player... or do you want to navigate your music in text mode ? (that's assuming you store your music on HDDs)
No issues with reiserfs... for a music only machine, ext3 is OK but I use the Pc for many other things, and reiserfs is so much better...
Hmm, well im going to use a web interface for my player and have the Linux box doing the work located somewhere else, so for me X isnt needed.
I guess it all depends on what front end people are going to use.
I guess it all depends on what front end people are going to use.
Tomorrow is a big day
Progress is going well here.
Have Linux 2.6.5 working very smoothly and quite fast. Has been a piece of cake, thus exonerating my fragile pc-ego
. Almost finished loading in tools and old files from the old desktop. It's a 100% current Debian system ("testing" version). The reason for the configuration given earlier was to put this box under my desk, kick out the old one and use the new one for both desktop and music stuff together for awhile. And it looks promising for that.
Later, when appropriate, I'll make a totally silent and dedicated box.
Also ready are 4-ch amp and biwired Vifa monitors. I ripped out their crossovers and soldered 12-gauge yellow outdoor Home Depot extension cord to each driver. Hey, it got a good review recently.
Tomorrow will be the first test of the new music system including BruteFIR. Sure would be nice to have some example files to start with
.
While puttering around, I hooked up a Turtle Beach Santa Cruz soundcard and have been playing through the biwired speakers. I remember when this card sounded ok to me, but it is quite bad actually. But it has some fun dsp effects that were amusing to listen to.
Still looking for jitter measurements and how-to.
See ya tomorrow.
-Robert
Progress is going well here.
Have Linux 2.6.5 working very smoothly and quite fast. Has been a piece of cake, thus exonerating my fragile pc-ego
. Almost finished loading in tools and old files from the old desktop. It's a 100% current Debian system ("testing" version). The reason for the configuration given earlier was to put this box under my desk, kick out the old one and use the new one for both desktop and music stuff together for awhile. And it looks promising for that.Later, when appropriate, I'll make a totally silent and dedicated box.
Also ready are 4-ch amp and biwired Vifa monitors. I ripped out their crossovers and soldered 12-gauge yellow outdoor Home Depot extension cord to each driver. Hey, it got a good review recently.
Tomorrow will be the first test of the new music system including BruteFIR. Sure would be nice to have some example files to start with
.While puttering around, I hooked up a Turtle Beach Santa Cruz soundcard and have been playing through the biwired speakers. I remember when this card sounded ok to me, but it is quite bad actually. But it has some fun dsp effects that were amusing to listen to.
Still looking for jitter measurements and how-to.
See ya tomorrow.
-Robert
- Status
- Not open for further replies.