Auraliti Music Player (and DAC)

[icebreaker]

From Auraliti website: "Auraliti Digital Music Player is the first easy to use, moderately priced music

file player designed for 24 bit 176.4 and 192 kHz high resolution audio files."

 

Looks interesting. The Auraliti has an internal DAC but works best as a digital memory player for a hi end DAC.

 

See here: http://auraliti.com/

 

and here: http://blog.stereophile.com/rmaf2009/bit-perfect_playback/#COMMENT

 

as well as: http://www.AudioAsylum.com/cgi/vt.mpl?f=pcaudio&m=62217

 

[Audio_ELF]

So it's a preconfigured Linux / Mpd system?

 

Any idea of what output card it uses?

 

[icebreaker]

I don't know to Q.2 It says it has a sound card so that is the same as an output card correct? Is the quality of output card important?

I was hoping to get feedback from others more in the know before I pulled the trigger.

 

[Brucemck2]

What "player" do you (or can you) use if you were using this as a transport only? I use J River currently ... assuming that wouldn't work?

 

[icebreaker]

"User interface: MPoD over customer supplied iPOD and several MPD free-ware clients available for PC and Mac"

 

I am not familiar with MPD or J River. New to me! I run out of a Mac Mini.

 

[The Computer Audiophile]

Hi Guys - I tweeted from RMAF about this one.

 

"This is something to keep an eye on. Seriously. Http://www.auraliti.com

2:17 PM Oct 2nd from Twitterrific"

 

It's custom everything using Linux and MPD. The least expensive model uses a Juli@ audio card. You can customize the system using a Lynx card as well. plus other great options improving the PSU etc... Damian Martin is incredibly smart when it comes to this stuff. I highly recommend talking to him about what Auraliti is doing. This system has wonderful potential.

 

[icebreaker]

I searched for Auraliti but I guess the search doesn't cover the "Twitter Tracker"

 

Thanks. I'll e-mail Ray and Damian about the possible sound card and PSU upgrades before I order(?)

 

Cheers,

 

[kana813]

"You can customize the system using a Lynx card as well. plus other great options improving the PSU etc..."

 

Chris-

 

There's no mention of any upgrades on the website.

 

It does say it has SPDIF 75 ohm BNC, wonder if it's transformer coupled.

 

 

 

[The Computer Audiophile]

Hi Dan - I spoke with Damian at RMAF extensively about the products being offered. There is a base model and one can upgrade from there.

 

[1audio]

Chris, Thanks for the complement. I don't know that I can live up to it.

 

The Auraliti Kit is the first version (more of a production version of our development platform). Its a Kit because you need to provide a controller (iPod touch, iPhone or laptop) and storage in the form of a USB stick or USB drive. As such its not complete in the sense necessary for a Big Box retailer.

 

It runs Linux, a very stripped down version with just what is necessary to "play" the files. It has no internal storage. It boots from flash with a read only file system. The box has no moving parts and is silent. It needs an ethernet connection to a WiFi hub for the controllers to connect to.

 

It does not have a big touch screen with fancy graphics, it doesn't rip content, manage or clean up your metadata or synchronize with your summer home. Its focused on playing high res files and will support 16 bit and 24 bit files with the following sample rates: 44.1KHz, 48KHz, 88.2KHz, 96KHz, 176.4KHz& 192KHz on the internal DAC and the SPDIF interface.

 

For the near term we are going to focus on extracting all we can from the Juli@ card. I have looked at the Lynx and at the RME cards. They both are good but Lynx support in Linux is very unsatisfactory for now. The RME support is much better but neither bring anything to the task that will improve the performance of this device a lot.

 

They both use PLL's to generate the clocks. PLL's are good but never as good as a clean crystal oscillator can be. Both cards are focused on recording, which is a very different environment from playback only. They need to be able to sync reliably to many sample rates and both have provisions for mixing different sample rates. For a device that plays a single stream only that is unnecessary. The Juli@ uses two crystal chains to generate the playback clocks, close to ideal for our task. The digital output is transformer coupled. We tie it to a 75 Ohm BNC to provide the cleanest path we can to an SPDIF device.

 

We do also plan power supply upgrades, but those will also be a later enhancement.

 

We are more focused on cost effective ways to make high resolution audio accessable with this product. The DAC on the sound card is OK and we will enhance it a little but any good external DAC should be better. We support USB up to 96K. I have no samples of a 176.4K or 192K USB DAC's to try so I can't comment above 96K. I also don't have a Firewire DAC to test with so I can't comment on Firewire yet.

 

We have plans for an upgrade output module that can provide additional performance options. However I cannot commit to any dates.

 

The $599 prerelease price will end when we start shipping at the beginning of November.

 

Demian Martin

www.auraliti.com

 

[ldolse]

Not to downplay Auraliti's efforts here, in fact I applaud them, this is great for the non-DIY crowd. However I'm curious about what this system offers over a DIY mpd system? I ask this as I'm 90% of the way through my own mpd music server build-out, also using the Juli@. Some of the comments on the blogs discuss some software customizations, and I'd love to hear more about what the pc hardware is.

 

[The Computer Audiophile]

However I'm curious about what this system offers over a DIY mpd system?

 

That's really an impossible question to answer as there is no DIY standard.

 

I do know that buiding a DIY MPD server is absolutely impossible for 99.9% of audiophiles / music lovers.

 

[Audio_ELF]

I suppose the same can be asked of any pre-configured turn-key system...

 

Some people just want to be able to plug in and go.

 

Eloise

 

[1audio]

If you are ready to undertake building your own MPD based player I'm all for it. However I would liken it to a cylinder head overhaul for a Jaguar. You can do it yourself and learn a whole lot but the difficulty level is high. The bumps in the road can be maddening. If you do build your own the customizations you can do are very extensive, all things that a non-techiie would be scared off by (not to mention a command line PC experience).

 

We have not changed the software. We did compile MPD specifically to support what we want to support, not every codec ever conceived of. The same for Alsa and the Kernel. We tweaked settings and parameters until the system was stable with our target hardware and have tried to lock it down. With Open Source everything morphs almost daily, which translates into potentially breaking every day. More than a few times I have had to start over because the last change was irreversable.

 

We are using the Juli@ (a card that deserves more attention here) and any of several ITX motherboards.

 

We have been trying to make it more appliance like and as simple as possible so it is accessible to a wider audience. Even so any computer audio product will be more complex than a CD player or Turntable by nature. Its not much more challenging than getting iTunes working with an airport express and an iPod touch remote. But much easier than building it yourself.

 

If you build it yourself you can play with things like real time kernels, schedulers, various remote control and local control alternatives, different driver tweaks, sample rate converters (I have tried to eliminate them but some are hard coded for some hardware, not ours thankfully) and many other possible things to try. The options make the usual audio tweaks look very short on variety. . . If you try these then you will know (keep detailed notes) how to undo them when they don't work. Google is your friend. Fortunately access to Google is free or I would be very very broke.

 

[IamKirk]

Did you get into realtime kernels or anything when developing? I am currently giving real time kernels and ecasound (low latency sound) a go on linux because I heard it makes quite a difference. For people that have an expensive system this would be a good solution for you (you also need lots of money lol). It definitely is a lot of work and fairly time consuming. MPD is amazingly flexible and sounds fantastic. A lot of people liken the linux audio to a cmp/cplay box on windows, but it runs as a daemon and is not nearly as limiting on the machine (unless you get into real time audio streaming of high def). You can run mpd on anything almost. You can ssh into the machine to run mpc (command line player). It has such a small overhead.

 

[1audio]

I could't find enough benefit for the effort for a real time kernel in this. The system does nothing else but play the audio. On a 176.4K FLAC it uses less than 25% of the CPU. Its worth experimenting but I am reluctant to add another point of failure right now.

 

Real Time Kernel http://en.wikipedia.org/wiki/Real-time_operating_system focuses on making sure events are processed at predictable times. When you have a lot going on (multitasking like crazy) this is important but far less when the box isn't doing much.

 

I'm reluctant to "tune by ear" for this stuff since I'm not convinced that the "better" sound is coming from software tweaks and not some other effect and not really sure its "better". If there is any metric that can be related it would make all this more interesting and focused. Otherwise

 

The great thing about our implementation with the whole system running from a removable flash device is that we can supply a revised version (instant upgrade) that can be swapped in in moments. And reversed in moments.

 

[The Computer Audiophile]

Hi Demain - Once again, I really like what you are doing and I encourage the Computer Audiophile readers to look into your products. At RMAF I told the seminar audience that Linux has the most potential in the long run to offer a toaster-like solution and the best sound. I also told them not to go purchase a machine and attempt to setup Linux with MPD. It would be a disaster if they didn't know what they were doing. There are quite a few DIYers here on the site, but the vast majority of readers are not the traditional DIY audience. They will setup a Mac and to a limited extent a Windows PC, but that's about it :~) Either way it's all very exciting and the wave of the future.

 

[ldolse]

Thanks for the extra info, it's appreciated. Anyway this post and the fact that mpd .15 has now added support for AIF and WAV tags inspired me to finish the project, or at least get it to a functioning state, not sure when I'll be done tweaking. Only thing I need to verify at this point is that the output is really bit-perfect... I come from a technical background, so the software aspects weren't too bad for me. I'd love to see some improvements over the existing process though, and I think it would be great advertising for you to contribute some of the future software stuff back to the community, so I hope you consider that. For a non-techie I agree the difficulty level is pretty high right now.

 

Still interested in your product as it matures, as I don't have much in the way of skills when it comes to hardware hacking/modding, and there are several things I'd like to see in that area. Really clean power is one, and modifying the Juli@ for better output/i2s would be very interesting (get rid of that horrible breakout cable!). A dedicated/tweaked motherboard design with non-essential functions removed/disabled would likely also be a big benefit. With the right hardware + software it should make things attractive for all but the most hardcore DIY'ers. It sounds like at least some of that is already on your radar. Chassis is also fairly important when it comes to this, everyone expects commercial stereo equipment to look good and perform well - vibration dampening/draining, etc. The only chassis pic I saw was one from RMAF - is that the final version of the chassis?

 

The AIF and WAV tag support worked superbly in the new version of mpd by the way. I'd actually gone to a number of open source projects and requested support for this 9-12 months ago, and thus far the mpd team is the only one that bit, so I've got to give some props to them for that.

 

[IamKirk]

From my understanding if you're using hwx,x or plugx,x as your output in mpd.conf (through also) that means it's connecting directly to your hardware (dac or soundcard). Not being passed through any mixers. To ensure your dac is running at the proper sample rate you can type "cat /proc/asound/device0/stream0" or whatever your card is listed as under "aplay -l". You can see the momentary frequency while you play a song. Just check a few times to make sure it's doing 44.1 or whatever you desire. Also, in your mpd.conf file you can use the command autoresample "no" (I think that's it, might not be though ). There are a couple of commands to push through 44.1, or really any bitrate I think.

 

[ldolse]

Really appreciated. Apparently the Juli@ uses naming that's quite a bit different though, and this doesn't match up with the aplay -l output. Here are the details for anyone else using Juli@:

 

My aplay -l output:

# aplay -l

**** List of PLAYBACK Hardware Devices ****

card 0: Juli [ESI Juli@], device 0: ICE1724 [iCE1724]

Subdevices: 1/1

Subdevice #0: subdevice #0

card 0: Juli [ESI Juli@], device 1: ICE1724 IEC958 [iCE1724 IEC958]

Subdevices: 0/1

Subdevice #0: subdevice #0

 

"card 0: Juli [ESI Juli@], device 1: ICE1724 IEC958" is the spdif output device

 

My /proc/asound directory listing:

card0 cards devices Juli modules oss pcm seq timers version

 

Bolded items are directories, Juli appears to be a symlink to card0. Going into either directory shows the following items:

ak4114 ak4358_codec ice1724 id midi0 oss_mixer pcm0c pcm0p pcm1c pcm1p

 

The directories appear to be the devices, after going through them one by one I figured out that pcm1p is the Juli@ spdif playback device, which contained some further subdirectories and files. Anyway the final file which needed to be cat'd was this (I didn't have any stream0 or anything resembling that):

 

#cat /proc/asound/Juli/pcm1p/sub0/hw_params

 

Which gave me this output:

access: RW_INTERLEAVED

format: S32_LE

subformat: STD

channels: 2

rate: 96000 (96000/1)

period_size: 2048

buffer_size: 8192

# cat info

card: 0

device: 1

subdevice: 0

stream: PLAYBACK

id: ICE1724 IEC958

name: ICE1724 IEC958

subname: subdevice #0

class: 0

subclass: 0

subdevices_count: 1

subdevices_avail: 0

 

The sample rate did change based on what track I was playing. I didn't see any way to get the sample bitrate though. There were several other files I could cat in that directory, but none seemed to provide me that info. I'm assuming if the samplerate was changing the bitrate was as also.

 

[1audio]

I have confirmed (with the driver's author) that using plughw: etc will pass the data at its native rate for all sample rates (except those below 44.1). You use plughw to convert the data from 24 bit to 32 bit which is what the card asks for. It also passes the 24 bits with no change (no software mixer). Using that in the MPD configuration file bypasses any other settings for Alsa. Its really clean (unless you want to do some sample rate things).

 

I'm not sure what you mean by bit rate? The sample rate defines the bit rate for the output. On all of the Juli@ cards I have looked at this just works. The output SPDIF is textbook (as it should be) and the internal clock jitter is 20 pS or less. (Its very hard to measure below 20 pS single shot, I don't know any commercial instruments that do).

 

I have found that MPD only recognizes one of the at least 4 different ways Wave files are tagged. There is no convergence on this that I have seen and I'm not sure how you would handle multiple tag formats for a file type, further what do you do if they don't agree?

 

We recommend FLAC since its consistent, becoming a de-facto standard, and we really cannot hear a difference in our box between FLAC and WAV. However we will support wav for those who want it.

 

We fully intend to contribute back to MPD (and fund any other worthwhile developers who want to contribute useful enhancements (please contact us if you have ideas)). We would like to see MPD become a common platform for this. Differentiating products through hardware and UI enhancements I think is a better future than a closed (dead end) platform. The open source core also means that many will look at the code and help make it better. Its hard to have dirty secrets when strangers are looking over your shoulder.

 

Demian Martin

auraliti

 

 

 

[ldolse]

By bitrate vs. sample rate I mean is it 16bit/44Khz, 20bit/44Khz, 24bit/48Khz, 24bit/96Khz, etc The samples are 'x' number of Khz, which I was able to see @ 44000 or 96000 based on my source file, but I couldn't see if the data was being passed with 16 or 24 bits per sample based on the source file.

 

The fact that plughw converts to 32bit concerns/confuses me a bit - doesn't it have to have the same bits as the original source file when it hits the DAC to be 'bit perfect'? Still need to look into that a bit further on my system to understand how I have it configured. I used the wizards to get ALSA running and mucked with .asoundrc & .mpdconf to output the data to spdif.

 

The convention mpd is using for wav and aiff is it's looking for a RIFF chunk with an id3v2 header. This is supported by a number of clients/rippers/editors, including itunes, windows media player 11, mediamonkey, dbpoweramp, tag & rename, and foobar (and now mpd), it's just that generally almost all of those pieces of software support either wav or aiff, but not both. No open source software supported either until mpd just recently, the primary reason being the most popular id3 tag library used in the open source community didn't/doesn't support it. The other tagging formats used in wav are pretty much only supported in recording tools, and thus aren't of a ton of interest. This is the mpd bugfix:

http://musicpd.org/mantis/view.php?id=2090

 

I'm not terribly surprised if compressed/uncompressed doesn't sound different in mpd, especially if you're using the RAM buffering option, because I believe FLAC gets buffered to RAM uncompressed (not 100% certain on that). Anyway there is a lot of debate on whether or not it sounds better, and the easiest way to avoid the debate is err on the uncompressed side of things. I haven't done enough listening tests on a good stereo to decide for myself, but storage is cheap.

 

Glad to hear your thoughts on contributing, looking forward to seeing things improve.

 

 

[Brucemck2]

Can you post screenshots, or even better a YouTube video, that shows the unit in action?

 

I've got a huge FLAC library that I manage in J River MC14. I'm interested in seeing how easy it is to take a playlist, or a subset of music, and get sound out of your unit.

 

From the posts above it appears very promising.

 

[1audio]

I will go back and see why we were not having much success with tagging of wav files. It seemed that there were several different places (chunks) that the different tag editors were placing the tags. The one we were using the most didn't agree with MPD on which chunk to insert the data.

 

I'm not playlist oriented myself. I'm much more album oriented. We have playlist support and it works fine (select the playlist on MPOD and it plays, skips forward or back much like an iPod etc.)

 

Navigating large libraries is always difficult. There is a search function of course.

 

[IamKirk]

I am also more of an albums guy, but I tend to just load my entire library into mpd under a playlist. If you choose to do it this way there are a few buffers you need to change in the mpd conf file. Max Playlist Size etc. I had to put it around 30000. It will still do gapless audio, shuffling around through my entire library or going through an album on repeat. I only use 16bit/44.1 though so I am not much help for high def audio streaming. MPD has a bunch of nice clients so you can typically find a decent playlist managing player that suits your needs. Most people probably use playlists a lot more than I do