# Can I use a MAC Mini for a "Car PC"? What all would I need?



## Niebur3

I HATE Windows. I HATE Windows. I HATE Windows. Now that I got that off my chest, can I do the "Car PC" thing using a Mac Mini? I currently have a P9 Combo and have converted all my computers to Apples and absolutely love them. I used to have people pay me to fix their PC's and know my fare share, just hated spending as much time with maintenance as using my PC's, so I am now an Apple guy (big learning curve, but made it to the other side)....lol. My work MacBook Pro has Windows using Parallels. 

I would love to do the "Car PC", but will not with Windows. Any help/advice with doing it with Apple would be appreciated. 

Thanks


----------



## 14642

That's funny. I use a Mac Mini, but I hate the Apple OS and the incompatibility with programs I wanted to use caused me to convert mine to Windows. 

Check out MP3car.com. They have plenty of solutions. There's also a site for Minis in cars too, but I can't remember what it's called.


----------



## MiniVanMan

I need a flippin' 20-24 pin converter for my power supply so I can start messing with the CarPC I'm building. Should be this coming week. Will be giving Linux a go. Looks like it'll do everything I need, but we'll see how complicated it'll be. Free is a hell of a hook to try something.


----------



## Niebur3

Free is a very good price. I would love to use a Mac for this and have it do all the processing and T/A, just don't know if it is possible yet. I really don't want to do an optical out to a bit.1 or anything, I would want it to do everything in lieu of the P9 combo.


----------



## ErinH

there's the tricky part. I was considering that route, but the hard part is finding an external (usb) sound card that has 8 channels. Maybe now there are options, but back when I was looking I couldn't find jack.


----------



## sleepingciv

long shot be get a hold of steve meade he uses a mac mini as a HU im sure he could give some light on the subject


----------



## BigAl205

MacVroom | Mac your ride!
MacCar - MP3Car.com


----------



## 14642

bikinpunk said:


> there's the tricky part. I was considering that route, but the hard part is finding an external (usb) sound card that has 8 channels. Maybe now there are options, but back when I was looking I couldn't find jack.


I use an Edirol 10-channel USB that works great, sounds great and is damn reliable. Not cheap, but not crazy expensive, either.


----------



## MiniVanMan

Andy Wehmeyer said:


> I use an Edirol 10-channel USB that works great, sounds great and is damn reliable. Not cheap, but not crazy expensive, either.


Gonna give a M-Audio 1010LT a whirl. It's not external, so if space is extremely tight, you've got a problem. 

I forgot I have a 20-24 pin adapter in another PC I'm not using. Doing some loading now as we speak. Hopefully the $15.00 2.0 ghz Celeron processor is up to the task. :worried:


----------



## Salad Fingers

I've done quite a bit of research on this, and am on the same page as you. iPhone, MacBook Pro, iMac, iPod... I'm all Apple. The **** just works, and makes sense. You'll need this

Carnetix CNX-P1900 Ver. 2.2 Dual Output 140 Watt 12V DC-DC Regulator

to provide the power, put it in sleep mode with ignition, and... well just read about it and you'll know that you need it. It will also provide the power for your touch screen monitor. I JUST ordered a W203 from the crutch for $450 shipped, and am still considering it and using the front row. Anyways, just do it, I pussed out 

Go Apple!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


----------



## Salad Fingers

... also, this looks to be the winner money, cool, and easiness wise

Preassembled Black Double Din LCD Frame with 7" Lilliput EBY701

DO IT!!!!!!!!!!!!!!!!!!!!!


----------



## Niebur3

Salad Fingers said:


> ... also, this looks to be the winner money, cool, and easiness wise
> 
> Preassembled Black Double Din LCD Frame with 7" Lilliput EBY701
> 
> DO IT!!!!!!!!!!!!!!!!!!!!!


So, my little bit of research shows I can go optical via the USB to an external processor. Now which processor??? Bit One or F#1 H900? Just dreaming at this point!!!


----------



## duckymcse

How about Bitone with M2Tech HiFace USB audio transport and Oyaide DB-510 coax digital cable?



Niebur3 said:


> So, my little bit of research shows I can go optical via the USB to an external processor. Now which processor??? Bit One or F#1 H900? Just dreaming at this point!!!


----------



## Salad Fingers

My buddy who (now) works back as an installer for pay reasons, said that the new LED tvs come with a smal 3.5 to optical adapter. Just heard this Wednesday, so haven't had a chance to look in to it, but that would sure simplify a lot


----------



## ErinH

duckymcse said:


> M2Tech HiFace USB audio transport


bad-ass!

Man, I really hate you guys.

This does bring into the issue of degradation of the audio source via digital volume control. But, then again, if you use the bitone as your volume knob, then it's no big deal at all. This is VERY interesting. I'm going to have to really look into this.


----------



## ErinH

I'm really curious to know what software you guys are using or looking at?

Windows or MAC O/S?
GPS software?
Bluetooth capability for hands free talking?
Voice commands?

These are the things that my pioneer has and I love it. If I can get BT, Voice recognition and good navigation, I'm there.
My experience with mac O/S is nil, so I wonder if running dual boot would be best for me?

I like the mac mini for its simplicity. I'm looking to start out simple and work my way up the chain of complexity, so I would keep my bitone DSP at least for the time being.


----------



## mosca

darn, I was commenting in another thread about a Mac mini CarPC setup that I'm getting up. I'm leaving a couple of links here to my comments to that thread:

http://www.diymobileaudio.com/forum...built-pc-high-end-headunit-2.html#post1004115

http://www.diymobileaudio.com/forum...built-pc-high-end-headunit-3.html#post1004513


----------



## mosca

bikinpunk said:


> I'm really curious to know what software you guys are using or looking at?
> 
> Windows or MAC O/S?
> GPS software?
> Bluetooth capability for hands free talking?
> Voice commands?
> 
> These are the things that my pioneer has and I love it. If I can get BT, Voice recognition and good navigation, I'm there.
> My experience with mac O/S is nil, so I wonder if running dual boot would be best for me?
> 
> I like the mac mini for its simplicity. I'm looking to start out simple and work my way up the chain of complexity, so I would keep my bitone DSP at least for the time being.


I will be using Mac OS with Windows XP virtualized for GPS or other apps that have no Mac version. that's because I wouldn't touch Windows with a 6 foot pole, and having it virtualized I can keep it sandboxed, if it goes to hell I still keep the host OS working fine.

I'm sharing some photos I made some time ago while I was trying a tactile screen, as I still have not mounted my CarPC. there are snaps at different res because I wanted to test what the screen was able to do.

iTunes in normal view @ 800x480:










iTunes in simple view @ 1000x600:










widgets @ 800x480:










here's the virtualized XP starting up in a window (takes in the range of 10s of seconds). this time the snapshot is @ 1000x600:










here's Garmin Navigator in the virtualized XP (full screen), which works fine with an external GPS receiver:










I still haven't looked into BT/handsfree.


----------



## mosca

Andy Wehmeyer said:


> I use an Edirol 10-channel USB that works great, sounds great and is damn reliable. Not cheap, but not crazy expensive, either.


¿can you share the specific model? I can't tell from his product list here Roland U.S. - Edirol

[in other thread] I was asking about this one MOTU.com - UltraLite-mk3 Hybrid Overview (sorry for repeating, just seems better to keep everything here).


----------



## ErinH

virtualized xp, huh? never heard of that. any more details you can give? links, etc?


----------



## mosca

bikinpunk said:


> bad-ass!
> 
> Man, I really hate you guys.
> 
> This does bring into the issue of degradation of the audio source via digital volume control. But, then again, if you use the bitone as your volume knob, then it's no big deal at all. This is VERY interesting. I'm going to have to really look into this.


as long as you don't want to go beyond 48 kHz sample resolutions... or the Bit One will lock up. from the manual:



> If digital signals at frequency higher than 48 kHz (96 - 192 kHz) are supplied, the Bit One locks up.


----------



## mosca

Salad Fingers said:


> I've done quite a bit of research on this, and am on the same page as you. iPhone, MacBook Pro, iMac, iPod... I'm all Apple. The **** just works, and makes sense. You'll need this
> 
> Carnetix CNX-P1900 Ver. 2.2 Dual Output 140 Watt 12V DC-DC Regulator
> 
> to provide the power, put it in sleep mode with ignition, and... well just read about it and you'll know that you need it. It will also provide the power for your touch screen monitor. I JUST ordered a W203 from the crutch for $450 shipped, and am still considering it and using the front row. Anyways, just do it, I pussed out


I use this one, but (for now) I will be starting up the whole system with the Bit One volume/power button, not with the ignition, because I prefer to have more control about the whole thing.

the Carnetix works great, to shut the system off it makes the Mini hibernate ("smart sleep" is called) and then shuts down the screen, the Bit One and the amps. to start up it wakes the Mini (less than 20 seconds), and then turns up the screen, the Bit One and the amps. and no pops to be heard!


----------



## mosca

forgot to put an image of my broken wet dream:










I can't use the Bit One soft on the mini because my display won't support 1024x768


----------



## mosca

bikinpunk said:


> virtualized xp, huh? never heard of that. any more details you can give? links, etc?


simply put, virtualization rocks. you can have as many guest OSes as available space you have. you pause them when you don't need them and close the virtualization app. when you need the guest OS again you just launch the app and resume operation from where you left it. you can also take snapshots, so if you install something and the guest OS (in a typical Windos fashion) goes haywire, you just ditch the current state and restore any historic snapshot you want.

the only caveat is that your Mini must be Intel (that means from 2006 until now). I run one with a 1.6 GHz Core Duo with 1 or 2 (can't remember now) GB of RAM and swapped the HD from a 160GB (which worked fine) to an 80 GB SSD one.

there's four popular virtualization systems. two paid, two free.

paid:

VMware Fusion: Run Windows and Chrome OS on Mac for Desktop Virtualization

Parallels Desktop 5 for Mac, Run Windows on Mac - Parallels Desktop Virtualization Software and Solutions

free:

VirtualBox

Q - [kju:]

I started using Q a long time ago (I make web development and need to run Windows browsers), but was pretty crude. then I switched to Parallels and used it from version 1 to 3, it was much better than Q but did some nasty things to the system, nothing to worry, but I didn't like what they were choosing to do. then it came Fusion and had much more respect for what Mac OSX is and that's what I'm using now.

VirtualBox was the last one to come to the game, it seems to work mostly well for beeing free, but it is not at the level of the paid ones. you will find lots of reviews and opinions and reviews about everyone of them via Google.

I've run all kinds of apps without problem, the only problem I've had until now (a couple of weeks ago) is with Woofer Tester 2, I have a thread on their forum woofertester.com • View forum - Woofer and Speaker Tester Information


----------



## mosca

bikinpunk said:


> These are the things that my pioneer has and I love it. If I can get BT, *Voice recognition* and good navigation, I'm there.


Mac OS X has voice recognition built in, but I can't give an opinion on how well or bad it works. here's a link to Apple's accessibility page Apple - Accessibility - Mac OS X - Physical and Motor Skills (info on the bottom of it).

here's a lifehacker's article on using Mac OS X voice recognition, though it is really old (2006) and I think things have changed a lot on the accessibility department.


----------



## duckymcse

M2TEch HiFace is selling like hotcake. I have to wait until April 12th for the vendor to get more shipment. I can't wait to order one of those and try it out. Goto head-fi forum and read up on it. 



bikinpunk said:


> bad-ass!
> 
> Man, I really hate you guys.
> 
> This does bring into the issue of degradation of the audio source via digital volume control. But, then again, if you use the bitone as your volume knob, then it's no big deal at all. This is VERY interesting. I'm going to have to really look into this.


----------



## t3sn4f2

bikinpunk said:


> bad-ass!
> 
> Man, I really hate you guys.
> 
> This does bring into the issue of degradation of the audio source via digital volume control. But, then again, if you use the bitone as your volume knob, then it's no big deal at all. This is VERY interesting. I'm going to have to really look into this.


That thing is a rip off. It's basically an m-audio transit that is able to support higher sample rates. So it's pointless to have that option since we, well I should say you, won't ever run anything higher then 16/44.

A transit will do the same, even bypass kmixer, for almost half the price.

If you want to go an even better route, get an EMU0404PCI for the same price as a transit. It does everything the M2 will do. Plus you get 2 volt studio quality analog ins/outs, 24/192 playback/record, 24/96 optical/coax ins/outs (S/PDIF or AES/EBU). Not to mention all the included software. It also hibernates just fine.


----------



## ErinH

my wife hates you guys as well...

I'm downloading vmware fusion as I type this. 

mosca, you said you're using the bitone for startup.. or you will be. Why did you choose this over using the mini?
Are you using the bitone's remote turn on to switch on the mini, or are you powering on the mini first?
Care to walk me through your startup sequence? 


I'm going to have a lot of questions... I'm REALLY starting to lean into this again. I lean into it about 4 times a year. 

I've got a lot of space in the dash; an 8" screen will fit very nicely in there without modification. The dash space is about 4.5x7". A 7" double din fits in with quite a bit of room to spare so an 8" should go pretty easily.


----------



## ErinH

t3sn4f2 said:


> EMU0404PCI


Problen with this is that it's not external. If I'm running a mac mini, I'm looking for something that's relatively external and easy to use.
Then again, IIRC, the mac mini's 3.5mm is actually digital out, too. So, that's a selling point.
I'd like to have 2 channel analog as well. Not sure how I could do this... does the mini have 2 channel stereo out, or only the 3.5mm headphone out? 


In general, just about anything I use would probably suffice. I'd just worry about low voltage outputs not being enough and causing me a raise in gain floor at the amps (I have a very slight one now that's not too bad, but if I have to crank gains more I'd run into issues).

The bottom line is I HAVE to have analog output, and analog input. The digital output is just a plus, to me. And I prefer a pretty high pre-out based on the reasoning above. If I can do this relatively easy via a USB add-on, or out of the mini itself, or a combination then I'm good to go.


----------



## 14642

mosca said:


> ¿can you share the specific model? I can't tell from his product list here Roland U.S. - Edirol
> 
> [in other thread] I was asking about this one MOTU.com - UltraLite-mk3 Hybrid Overview (sorry for repeating, just seems better to keep everything here).


 
It's this one:

Roland U.S. - UA-101: USB Audio Interface

Also, I suggest this power supply

CarNetix P2140

Finally, someone read me the riot act for dissing a firewire card in another thread, but my experience was that it wasn't compatible with the mini's firewire chip and no one would come clean, although there was plenty of online noise about similar problems.


----------



## duckymcse

Apparently, you have not a clue what you talking about.
Check out the link below and read a user review of the product.
USB to SPDIF converters shoot-out : EMU 0404 USB vs. Musiland Monitor 01 USD vs. Teralink-x vs. M2Tech hiFace - Head-Fi: Covering Headphones, Earphones and Portable Audio




t3sn4f2 said:


> That thing is a rip off. It's basically an m-audio transit that is able to support higher sample rates. So it's pointless to have that option since we, well I should say you, won't ever run anything higher then 16/44.
> 
> A transit will do the same, even bypass kmixer, for almost half the price.
> 
> If you want to go an even better route, get an EMU0404PCI for the same price as a transit. It does everything the M2 will do. Plus you get 2 volt studio quality analog ins/outs, 24/192 playback/record, 24/96 optical/coax ins/outs (S/PDIF or AES/EBU). Not to mention all the included software. It also hibernates just fine.


----------



## ErinH

mosca said:


> Mac OS X has voice recognition built in, but I can't give an opinion on how well or bad it works. here's a link to Apple's accessibility page Apple - Accessibility - Mac OS X - Physical and Motor Skills (info on the bottom of it).
> 
> here's a lifehacker's article on using Mac OS X voice recognition, though it is really old (2006) and I think things have changed a lot on the accessibility department.


Maybe there are front ends that work well with this? Mainly, I'm looking for VR for things like searching and playing music. IE: "play artist xxx", or "call xxx". My current headunit does these things and I LOVE that.


----------



## t3sn4f2

bikinpunk said:


> Problen with this is that it's not external. If I'm running a mac mini, I'm looking for something that's relatively external and easy to use.
> Then again, IIRC, the mac mini's 3.5mm is actually digital out, too. So, that's a selling point.
> I'd like to have 2 channel analog as well. Not sure how I could do this... does the mini have 2 channel stereo out, or only the 3.5mm headphone out?
> 
> 
> In general, just about anything I use would probably suffice. I'd just worry about low voltage outputs not being enough and causing me a raise in gain floor at the amps (I have a very slight one now that's not too bad, but if I have to crank gains more I'd run into issues).
> 
> The bottom line is I HAVE to have analog output, and analog input. The digital output is just a plus, to me. And I prefer a pretty high pre-out based on the reasoning above. If I can do this relatively easy via a USB add-on, or out of the mini itself, or a combination then I'm good to go.


Get an 0404USB then for $200, it has everything under the sun. 

*Sample Rates: 44.1, 48, 88.2, 96, 176.4, 192kHz from internal crystal (no sample rate conversion)* *
Bit Depth: *24-bit I/O, 32-bit processing *
USB 2.0 Hi-Speed 
- Full 24-bit resolution at all sample rates 
- 4in/4 out channels from 44.1-96kHz 
- 2 in/2 out channels from 176.4-192kHz 

*Zero-latency direct hardware monitoring* (disabled at 176.4-192kHz) 
Windows: ASIO2, WDM, MME - AC3 and DTS Passthru supported 
Macintosh: Apple CoreAudio and CoreMIDI - AC3 and DTS Passthru supported 
*Anti-Pop speaker protection minimizes noise during power on/off *
Ultra-low jitter clock subsystem: < 500ps RMS in PLL mode (48kHz, Coaxial S/PDIF Sync) 

Combo *Microphone Preamplifier*/Hi-Z/Line Inputs (2)

Type: E-MU XTC™ combo mic preamplifier and Hi-Z/line input w/ Soft Limiter 
A/D converter: AK5385A 
Gain Range: +60dB 
Frequency Response (min gain, 20Hz-20kHz): +0.0/-0.16dB 
Stereo Crosstalk (1kHz min gain, -1dBFS): < -110dB 
Hi-Z Line Input: 
- Input Impedance: 1Mohm 
- Max Level: +12dBV (14.2dBu) 
- Dynamic Range (A-weighted, 1kHz, min gain): 113dB 
- Signal-to-Noise Ratio (A-weighted, min gain): 113dB 
- THD+N (1kHz at -1dBFS, min gain): -101dB (.0009%) 
Microphone Preamplifier: 
- Input Impedance: 1.5Kohms 
- Max Level: +6dBV (+8.2dBu) 
- EIN (20Hz-20kHz, 150ohm, unweighted): -127dBu 
- *Signal-to-Noise Ratio (A-weighted, min gain): 112.5dB 
- THD+N (1kHz at -1dBFS, min gain): -101dB (.0009%) *
- Phantom Power: 48V 
- Soft Limiter: 5dB max compression (software selectable) 


Analog Line Outputs (2)

Type: balanced, AC-coupled, 2-pole low-pass differential filter 
D/A converter: AK4396 
Level (auto detect): 
*- Professional: +12dBV max (balanced) 4 volts clean RMS*
- *Consumer: +6dBV max (unbalanced) 2 volts clean RMS*

Frequency Response (20Hz - 20kHz): 0.06/-.035dB 
Dynamic Range (1kHz, A-weighted): 117dB 
*Signal-to-Noise Ratio (A-weighted): 117dB 
THD+N (1kHz at -1dBFS): -100dB (.001%) *
Stereo Crosstalk (1kHz at -1dBFS): < -114.5dB 

*Headphone Amplifier*
Type: Class-A power amplifier 
D/A converter: AK4396 (shared with Line Out) 
Gain Range: 60dB 
Maximum Output Power: 20mW 
Output Impedance: 22ohms 
Frequency Response (20Hz-20kHz): +0.06/-0.035dB 
Dynamic Range (A-weighted): 114dB 
Signal-to-Noise Ratio (A-weighted): 114dB 
THD+N (1kHz, max gain): 600ohm load: -95.5dB (.0018%) 
Stereo Crosstalk (1kHz at -1dBFS, 600 ohm load): < -85dB 

*Digital I/O

S/PDIF*: 
- 2 in/2 out coaxial (transformer coupled) 
- 2 in/2 out optical 
- AES/EBU or S/PDIF format (software selectable)* 

MIDI 
- 1 in, 1 out 


Synchronization

Internal crystal sync at 44.1, 48, 88.2, 96, 176.4, 192kHz 
External sample rate sync via 
- Optical S/PDIF (44.1 - 96kHz) 
- Coaxial S/PDIF (44.1 - 96kHz)


You can power it off a 12 volt regulated output from the carPC PS.


----------



## t3sn4f2

duckymcse said:


> Apparently, you have not a clue what you talking about.
> Check out the link below and read a user review of the product.
> USB to SPDIF converters shoot-out : EMU 0404 USB vs. Musiland Monitor 01 USD vs. Teralink-x vs. M2Tech hiFace - Head-Fi: Covering Headphones, Earphones and Portable Audio


"Note on USB cables :
I first discovered the effect of usb cables while using the EMU 0404 usb with the Audio-GD DAC-100. 
I was doing a comparison between the spdif input of the dac-100 and its usb input, and for a few trials I preferred the spdif input using the EMU 0404 as a transport. When I did the same experiment a little bit later, I found that I preferred the sound of theusb input of the DAC-100 over that of EMU 0404 as a transport. The only thing that changed between experiments is that I used a Belkin cable with the DAC-100. I repeated the experiment many times and could detect the differences : *the culprit was the stock usb cable that comes with the EMU 0404 that it is the worst sounding of all *(it is also poorly constructed with thin conductors and ferrite shielding).
That led me to buying different usb cables from Monster, Real cable, Belkin Gold, and finally Wireworld Ultraviolet. All of them have different sounds but the Wireworld is clearly superior sounding and it also allowed me to reach the lowest latency settings with the EMU 0404usb without suffering from crackling and pops."

Apperantly _I_ don't. :laugh:


----------



## mosca

bikinpunk said:


> mosca, you said you're using the bitone for startup.. or you will be. Why did you choose this over using the mini?
> Are you using the bitone's remote turn on to switch on the mini, or are you powering on the mini first?
> Care to walk me through your startup sequence?


I choose starting from the Bit One because I plan to use only the mini as a source. but you can set it up as you want, it all depends on how you connect stuff to the Carnetix P1900 (take a look at the MacPac too).

here's the installation manual http://carnetix.com/installation/CNX-P1900InstallationManualV2_1.pdf it has the startup/shudown sequences and all the possible setups.

in my setup I have connected the remote out from the Bit One to the Carnetix and to the amps.

when I turn up the Bit One, the amps and the Carnetix turn on, then the Carnetix sends power to the LCD screen (which as an auto power-on feature) and to the mini, and the mini gets also a signal to start up (this is done through a Y cable that comes in the MacPac and that you connect internally to the mini power button connector).

when I turn off the Bit One, the amps shut down, and the Carnetix gets a shut down signal, from here it sends a sleep signal to the mini, which will go to sleep, after 15/30 seconds it cuts the power off the mini and the LCD screen.

since I have activated the "smart sleep" feature on the mini (I use this pref panel when the power is cut the state it had when it went to sleep will be conserved. when you start it up again, it resumes that state (it displays an horizontal progress bar instead of a circular one when it does this). another cool thing about this smart sleep feature is that you can take the mini out of the car and it won't loose that state, so it is ready to resume if you want to use at home 

here's a snapshot the progress bar:


----------



## mosca

Andy Wehmeyer said:


> It's this one:
> 
> Roland U.S. - UA-101: USB Audio Interface


great, thanks.



Andy Wehmeyer said:


> Also, I suggest this power supply
> 
> CarNetix P2140


I have the P1900, it seems it should be able to keep up as it can push out up to 3 amps on the dedicated USB power out, and this "card" demands 1 amp.


----------



## duckymcse

If you read the entire review, the M2Tech HiFace range among his best. It beat out the Emu0404. It is not some M-Audio rip-off as you mentioned earlier. Beside if you read more on the forum, the Emu0404 is not very popular when it come to SQ. It is a decent audio interface, thought.



t3sn4f2 said:


> "Note on USB cables :
> I first discovered the effect of usb cables while using the EMU 0404 usb with the Audio-GD DAC-100.
> I was doing a comparison between the spdif input of the dac-100 and its usb input, and for a few trials I preferred the spdif input using the EMU 0404 as a transport. When I did the same experiment a little bit later, I found that I preferred the sound of theusb input of the DAC-100 over that of EMU 0404 as a transport. The only thing that changed between experiments is that I used a Belkin cable with the DAC-100. I repeated the experiment many times and could detect the differences : *the culprit was the stock usb cable that comes with the EMU 0404 that it is the worst sounding of all *(it is also poorly constructed with thin conductors and ferrite shielding).
> That led me to buying different usb cables from Monster, Real cable, Belkin Gold, and finally Wireworld Ultraviolet. All of them have different sounds but the Wireworld is clearly superior sounding and it also allowed me to reach the lowest latency settings with the EMU 0404usb without suffering from crackling and pops."
> 
> Apperantly _I_ don't. :laugh:


----------



## mosca

bikinpunk said:


> Then again, IIRC, the mac mini's 3.5mm is actually digital out, too. So, that's a selling point.
> I'd like to have 2 channel analog as well. Not sure how I could do this... does the mini have 2 channel stereo out, or only the 3.5mm headphone out?


only 1 output I'm afraid.


----------



## t3sn4f2

duckymcse said:


> If you read the entire review, the M2Tech HiFace range among his best. It beat out the Emu0404. It is not some M-Audio rip-off as you mentioned earlier. Beside if you read more on the forum, the Emu0404 is not very popular when it come to SQ. It is a decent audio interface, thought.


I won't be wasting my time reading a review about the digital outputs. Much less a subjective one based off what someone hears. I'll leave it at that.


----------



## mosca

bikinpunk said:


> Maybe there are front ends that work well with this? Mainly, I'm looking for VR for things like searching and playing music. IE: "play artist xxx", or "call xxx". My current headunit does these things and I LOVE that.


on the Mac side you have Ice3, which is a bit crude:










but via virtualization you can use others made for Linux or Windows, such as Centrafuse:










if you want perfect integration then Centrafuse + windows navigation app seems the way to go (I still haven't arrived to this stage of the project).

*edit*: sorry, I didn't get that you were suggesting using VR with the front ends. if it is a Mac frontend prolly it can be done, but if you choose Windows I don't know (yet).


----------



## 14642

t3sn4f2 said:


> I won't be wasting my time reading a review about the digital outputs. Much less a subjective one based off what someone hears. I'll leave it at that.


Aye, Mate. 'twould be a waste, indeed.


----------



## mosca

*Andy*, *t3sn4f2*, can you pinpoint me some readings so I can understand this (non?) issues about digital outputs? o maybe you can explain what you think in a paragraph or two... is it like using esoteric HDMI cables?


----------



## t3sn4f2

mosca said:


> *Andy*, *t3sn4f2*, can you pinpoint me some readings so I can understand this (non?) issues about digital outputs? o maybe you can explain what you think in a paragraph or two... *is it like using esoteric HDMI cables?*


Essentially yes, as long as you know how to send audio out of the PC correctly (ie no resampling or attenuating with inadequate software). 

Here's a test I ran on a plain old DVD player's Toslink output, using a plain old cheap fiber optic cable. If people feel they can hear differences that don't show up in a test like this, then they should buy what they need.



t3sn4f2 said:


> Below are some graphs from test results I just ran using Rightmark Audio Analyzer. I tested the SPDIF output of my "run of the mill" Sony DVP-NS400D DVD player (a *10 year old and $250 MSRP player). Externally synced by the player.
> 
> The test was run by burning the RMAA test file to a CD in CD audio format and playing it back through the player into my sound card's digital input. Then analyzed by the software.
> 
> I set it to recorded at 24bits/44kHz so that it would give a more accurate representation of the signal coming in.
> 
> What you see below are noise floor and IMD+Noise graphs, plus an EXTREME zoom on a random portion of each of the normal sized graph (please notice the increments on the x and y axis so you get an idea of just how zoomed in it is, ie 1Hz by .05dB increments).
> 
> The green portion of the graphs are the results for a software analysis of the test files run through the player being tested. That results is ALWAYS the same, as it is a bit analysis of a file. The white areas are the results of the player tested. Whenever you see a white part showing through the green line, it means that something happened and the sound was degraded somehow.
> 
> You can see that even when zoomed in to a 1Hz by .05dB scale, there is NEVER a white area to be seen.
> 
> Noise Floor:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Noise Floor Zoom:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> IMD+Noise:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> IMD+Noise Zoom:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I won't bother showing the results for the other test comparisons because they are also identical to the reference test file.
> 
> What do these results indicate in relation to what we can hear? Is there stuff that is audible to our ears yet does not show up on these standard test? I dunno, but when I look at a noise floor at -130dB and it has an identical frequency spectrum to the original, I wonder.*


----------



## mosca

thanks for the pointer, I'm going to read the original thread. in another forum I'm discussing with other people more or less about the same thing. they say that no computer with an audio card can come close to a p99... they say that even if you go losless you have process it again to get it through the digital out when reproducing it and this has bad effects on the sound.

or maybe I should just stop discussing there, because everybody states opinions as facts and nobody provides any data...


----------



## t3sn4f2

mosca said:


> thanks for the pointer, I'm going to read the original thread. in another forum I'm discussing with other people more or less about the same thing. they say that no computer with an audio card can come close to a p99... they say that even if you go losless you have process it again to get it through the digital out when reproducing it and this has bad effects on the sound.
> 
> *or maybe I should just stop discussing there, because everybody states opinions as facts and nobody provides any data*...


They'd be a good idea IMO.

Also note that in the test above, that is a measurement of a combination of a digital output from a player and a digital input to a computer. So the results you see are from 2 digital transformations. 

Think of it like sending a digital output from a head unit into a processor that had the ability to analyzed the basic unprocessed signal leaving it's DSP chip.

These ABSOLUTELY perfect results also happen when I test high resolution 24 bit 44kHz tracks from the S/PDIF output of my soundcard back into the input I used to test the DVD player.

Frequency response (from 40 Hz to 15 kHz), dB: +0.00, -0.00 
Noise level, dB (A): *-147.8* 
Dynamic range, dB (A): *133.4* 
THD, %: *0.0000 *
IMD + Noise, %: *0.0002 *
Stereo crosstalk, dB:* -148.7* 
IMD at 10 kHz, %: *0.0000 *

If those results are that perfect as well, how can someone hear differences in a format with MUCH less resolution.

(For anyone that has tried that 24 bit loopback and not gotten the result I claim. You need to play the file from a media player like foorbar or winamp and record the incoming signal on audacity at 24 bit 44kHz, then output a wav in 32 bit mode. Reason being RMAA cannot record well enough at those high level of resolution to not contaminate the results)


----------



## lycan

t3sn4f2 said:


> Essentially yes, as long as you know how to send audio out of the PC correctly (ie no resampling or attenuating with inadequate software).
> 
> Here's a test I ran on a plain old DVD player's Toslink output, using a plain old cheap fiber optic cable. If people feel they can hear differences that don't show up in a test like this, then they should buy what they need.


This analysis is blind to the problem of jitter. In other words, you didn't test the jitter of the interface, nor the sensitivity to the timebase in the digital-to-analog conversion.

Jitter is fundamentally an ANALOG problem. More precisely, it shows up at the boundary of the analog and digital domains. It will manifest at only one of two places : at the ADC on the recording end, or the DAC on the playback end. If it occurs at the ADC/recording end, then it WILL show up in FFT's of the digital data. If it occurs at the DAC/playback end, then it WILL NOT show up in FFT's of the digital data.

When we are discussing digital transmission in some format, down some cable, there are two *categories* worth considering :

1. The digital signal will be "latched" or received ONLY by another digital circuit. The only thing that matters, in this case, is that the "ones" and "zeros" are correctly interpreted as "ones" and "zeros". It's trivial, and it's the beauty of digital  The exact instance WHEN the transition from "one" to "zero" occurs is NOT important, as long as it happens within some broad "window of expectation". That window might be 100 nanoseconds wide, for 10MHz transmission. So the transition from "one" to "zero" might occur at 12 nanoseconds, 37 nanoseconds, or 74 nanoseconds ... and the system will NEVER know the difference. The digital receiver will only take a "snapshot photo" of the digital data every 100 nanoseconds, and it only has to distinguish between "one" and "zero". There's NO test you can do, to uncover a problem ... because there isn't one. ALL that maters is the digital "level" ... one or zero.

2. In this category, not only is the digital LEVEL important, but the EXACT instance WHEN the transition from "one" to "zero" happens is VITALLY important .. because the DAC uses this instance as the foundation for it's timebase, in the conversion to analog. Here, there's a BIG difference if the transition from "one" to "zero" happens at 12 nanoseconds versus 59 nanoseconds ... because the audio signal ITSELF that was supposed to occur at one point in time, now occurs at a DIFFERENT point in time, all because of a "sloppy timebase" derived from transmission down a cable.

Yes, it's confusing. And this is only ONE reason why the audio literature, by and large, has done nothing but confuse the topic of jitter. I'll tell you right now, most audio engineers don't understand it (and like i said, this is only one reason).

"How much is audible" remains a great question, of course, and one that we're hoping to address ... at least, put some boundaries on ... in the tutorials section.

But an FFT of the digital data sent down a cable will NOT show the jitter issue, because that's a "category 1" test of a "category 2" problem


----------



## t3sn4f2

lycan said:


> This analysis is blind to the problem of jitter. In other words, you didn't test the jitter of the interface, nor the sensitivity to the timebase in the digital-to-analog conversion.
> 
> Jitter is fundamentally an ANALOG problem. More precisely, it shows up at the boundary of the analog and digital domains. It will manifest at only one of two places : at the ADC on the recording end, or the DAC on the playback end. If it occurs at the ADC/recording end, then it WILL show up in FFT's of the digital data. If it occurs at the DAC/playback end, then it WILL NOT show up in FFT's of the digital data.
> 
> When we are discussing digital transmission in some format, down some cable, there are two *categories* worth considering :
> 
> 1. The digital signal will be "latched" or received ONLY by another digital circuit. The only thing that matters, in this case, is that the "ones" and "zeros" are correctly interpreted as "ones" and "zeros". It's trivial, and it's the beauty of digital  The exact instance WHEN the transition from "one" to "zero" occurs is NOT important, as long as it happens within some broad "window of expectation". That window might be 100 nanoseconds wide, for 10MHz transmission. So the transition from "one" to "zero" might occur at 12 nanoseconds, 37 nanoseconds, or 74 nanoseconds ... and the system will NEVER know the difference. The digital receiver will only take a "snapshot photo" of the digital data every 100 nanoseconds, and it only has to distinguish between "one" and "zero". There's NO test you can do, to uncover a problem ... because there isn't one. ALL that maters is the digital "level" ... one or zero.
> 
> 2. In this category, not only is the digital LEVEL important, but the EXACT instance WHEN the transition from "one" to "zero" happens is VITALLY important .. because the DAC uses this instance as the foundation for it's timebase, in the conversion to analog. Here, there's a BIG difference if the transition from "one" to "zero" happens at 12 nanoseconds versus 59 nanoseconds ... because the audio signal ITSELF that was supposed to occur at one point in time, now occurs at a DIFFERENT point in time, all because of a "sloppy timebase" derived from transmission down a cable.
> 
> Yes, it's confusing. And this is only ONE reason why the audio literature, by and large, has done nothing but confuse the topic of jitter. I'll tell you right now, most audio engineers don't understand it (and like i said, this is only one reason).
> 
> "How much is audible" remains a great question, of course, and one that we're hoping to address ... at least, put some boundaries on ... in the tutorials section.
> 
> *But an FFT of the digital data sent down a cable will NOT show the jitter issue, because that's a "category 1" test of a "category 2" problem *


I thought understood this the other day when I read your jitter thread but felt this "differences between digital outputs" was something completely separate.

Please bare with me, but just to be clear. You're saying that a properly designed and installed $50 dollar USB to S/PDIF converter _can_ sound different then a $1000 USB to S/PDIF converter _when_ hooked up to the same DAC because the jitter in the digital side will not come to light until all components in the chain come together and uniquely convert to analog?


----------



## lycan

What the hell, i'm going to elaborate on the jitter issue a bit  This is as simple as i can describe it, so stick with this post 

Let's say we've got 4 (four) audio samples, at a sampling rate of 50kHz (to make things simple). Our audio samples are base-10 "integer" samples of the audio waveform (yes, base-10 integers are one form of "digital").

We have a PERFECT recording system. As we "capture" our audio waveform, the four "samples" that we capture are :

0 microseconds : sample = +1932
20 microseconds : sample = -7458
40 microseconds : sample = -3916
60 microseconds : sample = +2974

Remember, the audio waveform is _always_ changing in time, but we captured these samples at these precise instants in time  The value of the sample, AND the exact time it was captured, are tightly linked!

Now we send these "digital" samples down a long cable. The transmission over the cable _degrades_ the signal, so here's what happens to the "samples" :

at 7 microseconds, the first sample = 1932.06 arrives
at 23 microseconds, the second sample = -7457.94 arrives
at 48 microseconds, the third sample = -3916.2 arrives
at 62 microseconds, the fourth sample = +2974.12 arrives

And the transmission works like this : the previous sample is "held" until the new one arrives.

Now at the receiving end of our long cable, we have TWO OPTIONS for how we "observe" these samples, in order to recreate the audio signal:

*OPTION 1*

We have a "perfect" local timebase, that ONLY observes these samples every 20 microseconds like a "snapshot" ... starting at 10 microseconds (to allow for some "fixed" transmission delay)

at 10 microseconds, first sample is captured & "rounded" to 1932
at 30 microseconds, second sample is captured & rounded to -7458
at 50 microseconds, third sample is captured & rounded to -3916
at 70 microseconds, fourth sample is captured & rounded to +2974

The amplitude "rounding" is the essence, beauty, and virtue of using digital signals for transmission & storage  We now play these samples back, AT THE SNAPSHOT INSTANTS. Our transmission & playback has been "perfect" ... nothing but a harmless 10 microsecond delay, constant for ALL samples.

This is also how an FFT capture of the received data would look ... perfect 

*OPTION 2*

We don't have a local timebase to capture or "snapshot" the incoming samples  So we just play them 5 microseconds _after they arrive_. Amplitudes are STILL rounded, though, maintaining that "virtue" of digital :

at 12 microseconds, first sample rounded to 1932 & played back
at 28 microseconds, second sample rounded to -7458 & played back
at 53 microseconds, third sample rounded to -3916 & played back
at 67 microseconds, fourth sample rounded to +2974 & played back

Now for the quiz:

Will *OPTION 2* sound the same as *OPTION 1*? After all, the signal is digital ... right?


----------



## t3sn4f2

lycan said:


> What the hell, i'm going to elaborate on the jitter issue a bit  This is as simple as i can describe it, so stick with this post
> 
> Let's say we've got 4 (four) audio samples, at a sampling rate of 50kHz (to make things simple). Our audio samples are base-10 "integer" samples of the audio waveform (yes, base-10 integers are one form of "digital").
> 
> We have a PERFECT recording system. As we "capture" our audio waveform, the four "samples" that we capture are :
> 
> 0 microseconds : sample = +1932
> 20 microseconds : sample = -7458
> 40 microseconds : sample = -3916
> 60 microseconds : sample = +2974
> 
> Remember, the audio waveform is _always_ changing in time, but we captured these samples at these precise instants in time  The value of the sample, AND the exact time it was captured, are tightly linked!
> 
> Now we send these "digital" samples down a long cable. The transmission over the cable _degrades_ the signal, so here's what happens to the "samples" :
> 
> at 7 microseconds, the first sample = 1932.06 arrives
> at 23 microseconds, the second sample = -7457.94 arrives
> at 48 microseconds, the third sample = -3916.2 arrives
> at 62 microseconds, the fourth sample = +2974.12 arrives
> 
> Now at the receiving end of our long cable, we have TWO OPTIONS for how we "observe" these samples, in order to recreate the audio signal:
> 
> *OPTION 1*
> 
> We have a "perfect" local timebase, that ONLY observes these samples every 20 microseconds like a "snapshot" ... starting at 10 microseconds (to allow for some "fixed" transmission delay)
> 
> at 10 microseconds, first sample is captured & "rounded" to 1932
> at 30 microseconds, second sample is captured & rounded to -7458
> at 50 microseconds, third sample is captured & rounded to -3916
> at 70 microseconds, fourth sample is captured & rounded to +2974
> 
> The amplitude "rounding" is the essence, beauty, and virtue of using digital signals for transmission & storage  We now play these samples back, AT THE SNAPSHOT INSTANTS. Our transmission & playback has been "perfect" ... nothing but a harmless 10 microsecond delay, constant for ALL samples.
> 
> This is also how an FFT capture of the received data would look ... perfect
> 
> *OPTION 2*
> 
> We don't have a local timebase to capture or "snapshot" the incoming samples  So we just play them 5 microseconds _after they arrive_. Amplitudes are STILL rounded, though, maintaining that "virtue" of digital :
> 
> at 12 microseconds, first sample rounded to 1932 & played back
> at 28 microseconds, the second sample rounded to -7458 & played back
> at 53 microseconds, the third sample rounded to -3916 & played back
> at 67 microseconds, the fourth sample rounded to +2974 & played back
> 
> Now for the quiz:
> 
> *Will OPTION 2 sound the same as OPTION 1? After all, the signal is digital ... right?  *


*Conventional wisdom says yes*. Lycan's jitter thread has yet to come to a conclusion. 

*Edit*: well not to your samples sound the same but to digital outputs.


----------



## lycan

t3sn4f2 said:


> Conventional wisdom say yes. Lycan's jitter thread has yet to come to a conclusion.


depends on what you mean by conventional 

If we recognize that the VALUE of the sample, and the TIME at which it is captured OR played back, are tightly linked ... then the answer is clearly no 

The samples in *OPTION 2* are being played back at the WRONG TIME. And there's no simple, constant delay that accounts for all the errors in TIME.

There's a FUNDAMENTAL difference between *OPTION 1* and *OPTION 2*, even though both are "digital".

Remember this : "digital" means the AMPLITUDES are "quantized", to make the AMPLITUDES very _insensitive_ to error. But AMPLITUDE and TIME are inexorably linked, for accurate playback of audio signals. So "digital" is only half the equation 

You can also think of it like this : digital audio payback is "real-time" (in the smallest, most micro-sense of the word) whereas _purely_ digital manipulation of signals ... including computer operating systems, FFT's, etc ... is NOT "real-time".

Or ... think of it this way. Would your FFT of the signal sent down the cable show the error of a DAC, that played back the signal at a 22kHz rate, instead of 44kHz? How does that 2x error in DAC playback show up in your FFT? What if the DAC played back at 43.9 kHz? What if the DAC playback frequency "wobbled" around 44kHz, and that "wobble" depended .. however small ... on the data format and cable? How does that show up in your FFT?


----------



## lycan

t3sn4f2 said:


> I thought understood this the other day when I read your jitter thread but felt this "differences between digital outputs" was something completely separate.
> 
> Please bare with me, but just to be clear. You're saying that a properly designed and installed $50 dollar USB to S/PDIF converter _can_ sound different then a $1000 USB to S/PDIF converter _when_ hooked up to the same DAC because the jitter in the digital side will not come to light until all components in the chain come together and uniquely convert to analog?


*Jitter is a "real-time", analog problem*. Purely digital signals are immune, because purely digital signals are only "observed" within a wide "window of expectation"; within this wide window, only amplitude matters.

In purely digital systems, both AMPLITUDE and TIME are quantized, for the highest levels of _immunity to error_. Purely digital systems are therefore NOT real-time.


----------



## t3sn4f2

lycan said:


> depends on what you mean by conventional
> 
> If we recognize that the VALUE of the sample, and the TIME at which it is captured OR played back, are tightly linked ... then the answer is clearly no
> 
> The samples in *OPTION 2* are being played back at the WRONG TIME. And there's no simple, constant delay that accounts for all the errors in TIME.
> 
> There's a FUNDAMENTAL difference between *OPTION 1* and *OPTION 2*, even though both are "digital".
> 
> Remember this : "digital" means the AMPLITUDES are "quantized", to make the AMPLITUDES very _insensitive_ to error. But AMPLITUDE and TIME are inexorably linked, for accurate playback of audio signals. So "digital" is only half the equation
> 
> You can also think of it like this : digital audio payback is "real-time" (in the smallest, most micro-sense of the word) whereas _purely_ digital manipulation of signals ... including computer operating systems, FFT's, etc ... is NOT "real-time".
> 
> Or ... think of it this way. Would your FFT of the signal sent down the cable show the error of a DAC, that played back the signal at a 22kHz rate, instead of 44kHz? How does that 2x error in DAC playback show up in your FFT? What if the DAC played back at 43.9 kHz? What if the DAC playback frequency "wobbled" around 44kHz? How does that show up in your FFT?


Please don't think I skipped over your post by posting the following question. I just don't know how to reply to it since I can't relate that to how music would sound differently in digital devices.

In your opinion, do you think there is someone that can tell the difference in the sound of this transport (ie transport ony, no DAC)










and this one?


----------



## lycan

t3sn4f2 said:


> Please don't think I skipped over your post by posting the following question. I just don't know how to reply to it since I can't relate that to how music would sound differently in digital devices.
> 
> In your opinion, do you think there is someone that can tell the difference in the sound of this transport (ie transport ony, no DAC)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> and this one?


It's impossible (for me, at least) to answer 

The question is one of jitter, of course, not data-errors. How bad is it? How much is audible ... and what are the "worst case" test signals (and DAC's) for revealing the sensitivity to jitter?

My only comment in this thread, has been tests that can _reveal_ jitter, versus those tests that are _blind_ to jitter.

Also ... i'll be the first to admit that i am NOT current on all the more recent data transmission formats, and how clocks are derived or recovered. I'm pretty familiar with S/PDIF and a couple better ones from years ago that separated clock from data, but i'm a bit out-of-touch. Is there a quick intro somewhere for digital-audio-over-USB (for example)?

i think I _can_ still add some value on the fundamental principles, though


----------



## mosca

now I'm lost with this transport issue


----------



## mosca

do we consider transport the part that goes from the reading of the data (be it a CD or an audio file) to a digital output?


----------



## t3sn4f2

mosca said:


> do we consider transport the part that goes from the reading of the data (be it a CD or an audio file) to a digital output?


Most people do now. It is or was normally used to talk about CD players being used as a digital output source only.


----------



## mosca

t3sn4f2 said:


> Most people do now. It is or was normally used to talk about CD players being used as a digital output source only.


okay, I understand.

here's a doubt regarding non physical formats and S/PDIF: when you reproduce a file whose sample rate is not one that matches the current link between the output of the transport and the input of the "receiver" (can't find a better word, sorry), who is in charge of the conversion? I suppose it would be software, so, might the software perform differently depending the platform developer or implementator, or there are concrete algorithms that every platform developer uses?.

I hope my question makes sense, I thought it was stupid when somebody asked me, but now I don't have it that clear


----------



## coefamily

Im currently Running just an HP Dreamscreeen and I love it. You can find them for less than 200 bucks these days.


----------



## t3sn4f2

mosca said:


> okay, I understand.
> 
> here's a doubt regarding non physical formats and S/PDIF: when you reproduce a file whose sample rate is not one that matches the current link between the output of the transport and the input of the "receiver" (can't find a better word, sorry), *who is in charge of the conversion*? I suppose it would be software, so, might the software perform differently depending the platform developer or implementator, or there are concrete algorithms that every platform developer uses?.
> 
> I hope my question makes sense, I thought it was stupid when somebody asked me, but now I don't have it that clear


The sample rate conversion software. I'd have to say that their must be a difference in quality because when I switch the sample rate of my soundcard from 44 to 48 when feeding it a 44kHz files, the sound turns to **** (IMD sweep goes into the single digits at frequencies over 10kHz, which is where I notice the degradation. So since sample rate conversion can be done correctly somewhere, if not it would not be an option, I say yes there is a difference in implementations. 

XP has a poor one. Vista and Windows 7 have good ones. Apparently my card has a poor but adjustable oone. But none of it matters since all of them are only useful when playing mutiple streams of different sample rates. All other times you simply set the sample rate to the output that matches the media you are playing and it works as it should.


----------



## mosca

lycan said:


> *OPTION 1*
> 
> We have a "perfect" local timebase, that ONLY observes these samples every 20 microseconds like a "snapshot" ... starting at 10 microseconds (to allow for some "fixed" transmission delay)
> 
> at 10 microseconds, first sample is captured & "rounded" to 1932
> at 30 microseconds, second sample is captured & rounded to -7458
> at 50 microseconds, third sample is captured & rounded to -3916
> at 70 microseconds, fourth sample is captured & rounded to +2974
> 
> The amplitude "rounding" is the essence, beauty, and virtue of using digital signals for transmission & storage  We now play these samples back, AT THE SNAPSHOT INSTANTS. Our transmission & playback has been "perfect" ... nothing but a harmless 10 microsecond delay, constant for ALL samples.


how do you know how to round?

also, why doesn't everybody use local timebases? do they cost too much?


----------



## mosca

t3sn4f2 said:


> The sample rate conversion software. I'd have to say that their must be a difference in quality because when I switch the sample rate of my soundcard from 44 to 48 when feeding it a 44kHz files, the sound turns to **** (IMD sweep goes into the single digits at frequencies over 10kHz, which is where I notice the degradation. So since sample rate conversion can be done correctly somewhere, if not it would not be an option, I say yes there is a difference in implementations.





t3sn4f2 said:


> XP has a poor one. Vista and Windows 7 have good ones. Apparently my card has a poor but adjustable oone. But none of it matters since all of them are only useful when playing mutiple streams of different sample rates. All other times you simply set the sample rate to the output that matches the media you are playing and it works as it should.


so if we were playing files with different sample rates (I'm thinking in a wors case scenario here), who would be doing the conversion? is it at the codec level? is it at the player level? is it at the OS (drivers) level?


----------



## lycan

mosca said:


> how do you know how to round?


It's easy ... round to the nearest integer. Of course, in base-2 arithmetic that digital machines use, the circuitry just rounds to the nearest binary level, when it receives a digital signal.


> also, why doesn't everybody use local timebases? do they cost too much?


No ... the problem is that your local timebase will not frequency-match the timebase of the source (for example, the transport that's reading the data from the CD ... remember those?  ) that's streaming the digital signal to you!

So the options are these :

1. "recover" a clock from the _data stream_ that's coming at you (by "you", i mean the DAC). But this incurs jitter ... and, a nasty type called inter-symbol interference. This is how S/PDIF works.

2. Use a clean clock at the DAC (where it belongs), and send that clock to the transport ... so the transport is now the "slave" and the DAC is the "master". The transport doesn't care about jitter (it's "Category 1", referring to my discussion above). This is the highest-performance option, but it requires ... horror of horrors ... another conductor.

3. Use a boat-load of local memory to store data, and read that data out with a clean clock local to the DAC.

4. Use asychronous sample rate conversion, in hardware. Topic for another day. But some crazy dude did a _long_ thread on this, a _long_ time ago, over on diyaudio.com  It's compatible with S/PDIF, and probably other formats as well.


----------



## t3sn4f2

mosca said:


> so if we were playing files with different sample rates (I'm thinking in a wors case scenario here), who would be doing the conversion? is it at the codec level? is it at the player level? is it at the OS (drivers) level?


I'm pretty sure the OS is the only one that can and is suppose to do sample rate conversion. It's even an option on control panel's sound icon. The player decodes at said rate and outputs to the driver. The soundcard just runs its DSP at the specified rate you set to match the incoming stream. That's probably why mine sounds like crap when I don't match sample rates, it doesn't convert it just plays it as best it can. The instructions tell you to manually set the cards DSP sample rate to match the incoming windows rates.


----------



## mosca

lycan said:


> It's easy ... round to the nearest integer. Of course, in base-2 arithmetic that digital machines use, the circuitry just rounds to the nearest binary level, when it receives a digital signal.


so the error is know to be below a certain cut points always?



lycan said:


> No ... the problem is that your local timebase will not frequency-match the timebase of the source (for example, the transport that's reading the data from the CD ... remember those?  ) that's streaming the digital signal to you!


can we extend this to a digital file? the timebase that counts there is the one that generates the software player?



lycan said:


> So the options are these :
> 
> 1. "recover" a clock from the _data stream_ that's coming at you (by "you", i mean the DAC). But this incurs jitter ... and, a nasty type called inter-symbol interference. This is how S/PDIF works.
> 
> 2. Use a clean clock at the DAC (where it belongs), and send that clock to the transport ... so the transport is now the "slave" and the DAC is the "master". The transport doesn't care about jitter (it's "Category 1", referring to my discussion above). This is the highest-performance option, but it requires ... horror of horrors ... another conductor.
> 
> 3. Use a boat-load of local memory to store data, and read that data out with a clean clock local to the DAC.
> 
> 4. Use asychronous sample rate conversion, in hardware. Topic for another day. But some crazy dude did a _long_ thread on this, a _long_ time ago, over on diyaudio.com  It's compatible with S/PDIF, and probably other formats as well.


so via S/PDIF we're actually ****ed up, unless we went the "crady dude" route... how do the other two alternatives translate into the real world? (i.e. the name of "interconnects" that are in use right now).


----------



## mosca

t3sn4f2 said:


> I'm pretty sure the OS is the only one that can and is suppose to do sample rate conversion. It's even an option on control panel's sound icon. The player decodes at said rate and outputs to the driver. The soundcard just runs its DSP at the specified rate you set to match the incoming stream. That's probably why mine sounds like crap when I don't match sample rates, it doesn't convert it just plays it as best it can. The instructions tell you to manually set the cards DSP sample rate to match the incoming windows rates.


okay, it seems logic enough (though the "pretty sure" part bothers me a bit )


----------



## t3sn4f2

mosca said:


> okay, it seems logic enough (though the "pretty sure" part bothers me a bit )


I had to put that in there to cover my ass.  I'll always put it that way unless I'm sure about something.


----------



## mosca

I took a walk on the "PC Based" subforum at diyAudio, and found people recommending this: Item Audio: SuperPro 24 bit DAC

whose copy text says this:



> It's also revealing enough to show the differences between digital cables: USB in particular.


----------



## mosca

they have more curious content here Cullen PS Audio Digital Link 3 DAC



> A good USB cable will really make this DAC sing. It also responds well to power cable upgrades.


----------



## t3sn4f2

mosca said:


> they have more curious content here Cullen PS Audio Digital Link 3 DAC


Don't forget to also get their noise harvester and their $100 wall outlet and their $700 power cable and on and on........


----------



## mosca

t3sn4f2 said:


> Don't forget to also get their noise harvester and their $100 wall outlet and their $700 power cable and on and on........


but "It helps connected equipment enjoy a breathtaking openness, with quick transients combined with a warmth and richness that we have never before experienced."! :biggrinflip:


----------



## mosca

mosca said:


> so via S/PDIF we're actually ****ed up, unless we went the "crazy dude" route... how do the other two alternatives translate into the real world? (i.e. the name of "interconnects" that are in use right now).


ok, I found one possible alternative: I²S - Wikipedia, the free encyclopedia

I stumbled there while checking the DSP MiniDSP - miniDSP Kits on this thread DIY DSP - DIYMA.com


----------



## rain27

If I am understanding correctly, this is what I would need to install a Mac Mini:

1. Carnetix 1900 power supply
2. ART USB Dual Pre (suggested by Andy W.)
3. LCD touchscreen

I plan on hooking the Mac Mini up to an MS-8.

Is there anything else I would need?

By the way, did any of you guys that were considering this end up trying out the Mac Mini in your car?

Also, what are the cons to using a Mac Mini rather than a traditional multimedia source unit?


----------



## m3gunner

If the MS-8 supports optical input, you don't need the USB unit as all Intel based Minis (since 2006) have an optical out on their output (headphone) jack.

I'm tossing around the idea of running one of my Minis with my BitOne.

The cons:

1. It's a computer so it's more likely to crash (but way less likely if you stay away from ****ty Microsoft software).
2. OK, I don't see a #2.

Sorry... I'm late to this one. I've been tossing around the idea of doing this myself and I have everything to make it happen. I just need to find some time to do it.


----------



## t3sn4f2

m3gunner said:


> If the MS-8 supports optical input, you don't need the USB unit as all Intel based Minis (since 2006) have an optical out on their output (headphone) jack.
> 
> I'm tossing around the idea of running one of my Minis with my BitOne.
> 
> The cons:
> 
> 1. It's a computer so it's more likely to crash (but way less likely if you stay away from ****ty Microsoft software).
> 2. OK, I don't see a #2.
> 
> Sorry... I'm late to this one. I've been tossing around the idea of doing this myself and I have everything to make it happen. I just need to find some time to do it.


FYI, the MS-8 runs at 48kHz. Sending it a 44.1Hz CD or media file source without a proper sample rate conversion will result in severe distortion (ie as high as 5% IMD). 

More info. on that here

So if a mod becomes available someday you will either need an Asynchronous Sample Rate Converter (ASRC) device like this one to put in between the S/PDIF or i2s I/O's of the PC and MS-8. 

Or you will need some type of QUALITY SSRC plug-in for the media player you will use for media playback.

Or you will need a soundcard that comes with a option to do sample rate conversion correctly.

That being said, the only reason I would go through those step and send a digital input into the MS-8 is when the source is mounted for from the MS-8 where it could pick up noise from the car and/or if the source is severely limited in preamp voltage where it force you to take too much gain out of the devices downstream, resulting in an audible noise floor.

With a car PC that will likely be mounted close to the MS-8 and ground to the same spot, I would use the analog outputs from a high resolution capable soundcard (preferably PCI since IME they come back from hibernation just fine. A high resolution card like say an EMU0404PCI ($100) will have a DAC output stage that is far cleaner then what a CD format can itself do (ie -116dB noise floor without a signal versus ~-97dB from a CD format). 

IOW as long the soundcard has the output voltage you need for the next device (in this case 2 volts RMS) and it does not pick up noise from the SHORT signal chain, you WILL NOT hear a difference between it and a digital transmission, and the difference will barely be measurable with an analysis instrument.

Further more, the MS-8 will have a high resolution 24bit ADC, just like the cards DAC which will be capable of making the analog to digital conversion without any degradation to the sound, the same way the sound card's DAC won't degrade it.

Personally I would use a purpose built CarPC case and an EMU1212M soundcard that has 7.5 volts RMS balanced outputs ($150 MSRP, 120dB S/N ratio), then feed it into the MS-8's speaker level inputs so that I you can get the 2.8 volts RMS out of the MS-8 that you can't get when sending it only 2 volts RMS unbalanced to the inputs. Only complication with that setup is that you need to fit two PCI cards into a CarPC case.


----------



## 14642

Guys,
I use a Mac Mini. The analog output is crap--c.500mV. Don't use that. Any USB soundcard that will output a balanced signal will isolate the system from noise if you're using an MS-8 and you won't have to be concerned with all of this.

All of this hassle and confusion about resampling is precisely why MS-8 has no digital input. We can provide much more predictable performance if we do the conversion inside MS-8. Differential inputs make noise a non-issue and that's the reason to use analog input. 

FWIW, we've discovered that the sample rates in head units are often not precisely 44.1k. The error isn't usually audible and is never audible enough to be annoying, but during the input setup routine, MS-8 looks for precisely what's on the setup disc. Initially we assumed that 44.1k was agiven and we could count on that so that MS-8 could correlate what it receives to what it expects to receive. Basically, our ability to determine the delay and the EQ of the head unit's output signal originally depended on 44.1k being reliable. Since it isn't, Adam had to invent a way to read the error and adjust the algorithm so that high frequencies would correlate so the unit could determine the delay used on tweeter and midrange channels, depending on the crossover. The greater the error, the lower the frequency where the algorithm couldn't correlate. Fortunately, we caught this during beta testing and the production units include this "resampler".

We've applied for a patent for the entire input setup routine and this resampler is part of it. 

Finally, don't be too concerned with the number of A/D and D/A conversions in your system. There are three in my signal chain and I listen only to MP3 anad M4A files--M4A at 128k and MP3 at 256 or 320. Sounds great. Don't sweat the small stuff and all of this maniacal desire to maintain a digital signal transfer is tantamount to the old concern about the quality of RCA cables, silver solder, gold ends, etc. 

It doesn't matter whether the signal degradation can be measured. It doesn't even matter if the degradation is audible in an A/B comparison. It only matters if the degradation is annoying when you listen to it. For a reality check on where to spend your money and time, measure an impulse response from the input of your signal chain to the ELECTRICAL output. Then measure an impulse response from the input of your signal chain to the acoustic ouptut at the listening position. Compare the two. You'll clearly see that MUCH more degradation happens AFTER the amplifier and that's what you should work on.


----------

