New OSX Opensource audiophile player : Audirvana

[damien78]

Audirvana is an opensource project for an audiophile player for OSX.

I've started this project for the fun of getting my hands in this domain and try to get more knowledge of the sources of sound quality.

 

You can download it from http://audirvana.googlecode.com

 

Any comments, and contributions are welcome!

 

 

* Native playing of FLAC, libSndFile (WAV, AIFF, ...), ALAC and other quicktime formats (AAC, MP3, ...)

* Direct sound path, directly to the CoreAudio HAL for pure bit perfect sound

* Audio Device exclusive access mode

* HAL I/O using DAC native physical formats "Integer Mode" (instead of CoreAudio 32bit float)

* Automatic sample rate switching

* Up/Oversampling capability

* Plays completely from memory

** Tracks are loaded, decoded and sample rate converted in a memory buffer before being played

** Minimizing CPU and hard drive activity to lessen sources of interference

* Gapless playback by using a double buffering mechanism (playing track and next track)

* Transparent split load for loading tracks of any size

* Background tracks loading/decoding (including sample rate conversion)

* Playlist (m3u & m3u8 formats) load/save

* Handles Apple IR Remote

* Automated updates downloading (using Sparkle)

 

Currently works on 10.6 Intel Macs with any CoreAudio compatible DAC

 

This is still a beta release for this opensource project in active development.

 

Here is a tentative TODO list, and as I have a life outside this project any contribution is welcome:

* Dithering implementation, with tests on 16bit files improvement

* Tracks library with iTunes database access and folders crawling (mainly for FLAC)

* Remote control (through UPnP control point?)

* And bug fixes...

 

[damien78]

Encore: It should work as Hiface EVO is CoreAudio compatible (= has drivers for the Mac). But I don't have one to confirm.

 

Anyway, just try by yourself!

 

[damien78]

In the playlist window (currently titled untitled until I implement the load/save mechanism), you either click on the '+' button that raises a file open dialog, or you drag & drop from the finder or itunes. And then click on play.

 

[damien78]

Thanks!

 

On the TODO list... Will also include playlist (m3u & xspf formats) loading from command line, or dbl click in Finder.

 

But highest priority is using Grand Central Dispatch to get the load operations perform in the background and not delay playback start.

 

[damien78]

Joe: thanks for the proposal!

 

First way is to find bugs and a way to easily reproduce them. In this case you can even use the bug tracker in google code (issues tab).

 

Second if you have Obj-C coding expertise is to propose to take one of the TODO list items (UPnP experts are welcome...)

 

Third if you have audio algorithm expertise, I'm always interested in innovative proposals to implement. That was one of my initial goals when I started this project.

One of them is to get a very good noise shaping dithering algo to implement not too destructive dithering volume control.

Other ideas in 16/44.1 improvement are welcome.

 

Damien

 

[damien78]

One and a half:"CPU over" alarm is mainly used for debugging purposes.

It is triggered by CoreAudio HAL that indicates the reading callback that fills the driver buffer has taken too long time.

Most of the time it means missed samples, and that glitch should be audible.

 

When are you getting this alarm ? What occurence ? Is it when switching track? With or without sample rate change ?

Any detail you may have will be very useful.

 

Adding FF & RW buttons, though redundant with the slider can be nice and is very easy to implement, the longest part is drawing the buttons BTW, what increment? 10s as for the Apple remote buttons ?

 

SteveS1: I'll look into this iTunes drag&drop, should be "fixable"

 

[damien78]

Fixed in version 0.1b

 

[damien78]

Lizard_King: Sorry, it won't work on ppc. I already use 10.6 only APIs, and next step will be strong use of GCD.

 

Furthermore, Intel modern CPUs (all Core included) ensure 64bit simple operations are atomic if correctly aligned, thing you don't have with ppc.

And this feature is of great help to avoid any locks-triggering-kernel-traps that give performance penalty and thus degrade SQ.

 

[damien78]

I enabled the precision loss warnings to help hunting data loss.

But my main dev config is 64bit/debug, and some data types have reduced precision in 32bit mode, thus generating the warnings during the i386 build. Anymay, most of the users will run the 64bit version.

 

The external libs (libsndfile, libsamplerate, taglib, flac, ogg, ...) are quite stable now, and so I did not feel it justifies the hassle of distributing the app with dynlibs to maintain.

I feel distributing a zip that basically contains only the app package the user only need to drag'n'drop in his apps folder is worth it.

So a fink package won't be useful in this regard, but thanks for the proposal.

 

[damien78]

DanRubin: Ok, it seems you don't have the font "Futura" installed on your mini, and that's the cause.

I'll code a gentle fallback though to prevent the exception.

 

[damien78]

The main ennemy of memory playback is the OS swapping the buffers.

That's why I've limited the allocable buffers size to total RAM - 1GB to ensure the OS gets enough of it and does not trigger swapping.

Unfortunately it doesn't seem there is an easy way (but if anyone knows...) to declare a user level mem block to be resident in RAM.

 

That may explain what One and a half has experienced.

wgscott: can you check the available mem you have when playing and encountering the dropouts?

 

Anyway, it seems there is a mem leak, and this may be the #1 cause and on my fixing list.

Another way to reduce the realtime mem access need is to increase the driver buffer size. Until I implement it, you can change it by yourself using the HALLab application.

 

[damien78]

I've fixed the mem leak that was causing the tracks buffers not to be freed, and thus increasing mem footprint up to make mem swap, thus causing cpu over alarms, audio dropouts.

 

wgscott: can you retest and tell me if it's better now ?

 

DanRubin: I've implemented the fallback to the standard label font if the Futura font can't be found.

 

Damien

 

[damien78]

DanRubin: The crash occurs when the CoreAudio loader (using Apple loader API) tries to read from the file.

The track is added without issue to the playlist (with title, artist, ... information ok) I assume.

Is there anything special about this file (file itself, location e.g. network volume, ...) ? Are you able to play the file in iTunes ?

Is it occuring all the time ?

 

But this may not be the cause, re-reading your crash log indicates "Crashed Thread: 2". Can you paste it again (or send it to me in PM) with the full log, especially the crashed thread call stack ?

 

[damien78]

Making a PPC version will not only mean replacing the currently few 10.6 API calls, but also implement some synchronization mechanisms that are not needed for Intel CPUs.

Furthermore I'll make use of 10.6-only feature (GCD) in a very next release to implement background load.

 

[damien78]

wgscott: You named it, the uncompressed size exceeds the max buffer size you have on your system (1GB for 2 buffers = 512MB each = ~23mn @ 48kHz).

Implementing split load to allow large files load is in my todo list, but not in 1st position... Anyway, you're not going to miss this Mahler piece, are you?

 

Good to hear you don't have dropouts anymore!

 

[damien78]

lovejoy: First of all thanks a lot for this comment!

 

I've fixed the mem leak that was causing mem swap and thus the gliches after some time. You can get it from googlecode, it's version 0.1d.

 

Damien

 

[damien78]

Audirvana is samplerate agnostic: if the DAC handles the sample rate it'll directly send the audio stream, and if not, it'll sample convert it to the highest the DAC can handle.

Note that this sample conversion process takes time (up to 1mn for a 10mn track), and currently delays first track playback. This annoyance will disappear when I'll implement background loading.

 

So 24/96, 24/176.4, 24/192,... are handled.

 

Damien

 

[damien78]

What do you mean exactly by VST wrapper ?

Is it using ASIO for output ? In this case this is a no, as ASIO will add overhead over bare CoreAudio and thus decrease sound quality.

Is it to add VST filters in the signal ?

I'm not sure it is the highest priority, as this will deviate from this program first goal: pure unaltered music with highest quality.

It will need to be applied during track load and not realtime though.

 

Damien

 

[damien78]

The new version 0.1d (available in audirvana.googlecode.com) fixes the issues found with these DACs that provide multiple single channel streams instead of a single multichannel one.

 

Damien

 

[damien78]

It is capped to RAM - 1GB to leave enough to the OS & other background processes to avoid annoying swapping.

 

Split loading will enable to overcome this limit, and it's in the TODO list...

 

[damien78]

Adding the "Prune" feature is a no brainer, I'll include it in next update. Though I won't have much time for coding this week.

 

Playlist load/save is in the TODO list.

 

BTW, I've sorted the TODO list in googlecode by priority order.

 

For iTunes integration, I have some ideas to make it unnecessary...

 

[damien78]

Hi Swrbad,

 

Can you PM me the contents of the debug info window (you get it from the Audirvana menu)?

It'll help me find out what happens.

 

Damien

 

[damien78]

• Added Prune playlist menu command: remove all playlist items except the playing track
  
• Added option (enabled by default) to switch I/O buffer to maximum size. This maxes the latency, but minimizes the CPU load. And should improve SQ.
  
• Fix for continuously variable sample rate devices whose only maximum sample rate was used
  

 

This release now uses Sparkle for automated updates download, so you shouldn't need to monitor google code anymore!

 

swrbad: The debug logs show that the HiFace is correctly selected. Anyway, only one sample rate was detected thus leading to use of sample rate converter. And very long load time until I implement background loading.

If this isn't fixed with this new release, can you paste the new debug logs ?

 

[damien78]

The main thing is that computers are a source of electromagnetic noise.

You can even hear some noise generated by the gfx cards/screen cable when moving a window on some setups...

And of noise on the powerline. So the less the computer is active, the less it makes noise. Hard Drive being much more noiser than CPU activity (longer wires, higher current).

But there are other factors less obvious (e.g. noise main frequencies more prone to make interference)...

 

Most audio apps on mac (including afplay) use the AudioUnit high-level API that enables lots of services (effects plugins...).

Audiophile players address the DAC at the lowest level, that is the CoreAudio HAL, and try to minimize their CPU load.

 

BTW, can you try the latest Audirvana version (0.1.6/0.1f) with the "Use max I/O buffer size" set to on ? It'll further decrease CPU load.

 

Damien

 

[damien78]

Do you get the "CPU over" warning with it?

Can you also try with unchecking the "Use max I/O buffer size" ? You may need to restart Audirvana as I missed to implement restoring the initial buffer size upon stop in this version.