New OSX Opensource audiophile player : Audirvana

[damien78]

Good to know that clicking happens only when maximizing buffer size. One thing that puzzles me is that the max buffer size is not a power of two. As most coders think in power of two...

I'll change it in next release so that max buffer size is the highest power of two allowed for the device. (e.g. 8192 for tpan's DAC). You'll tell me if that helps.

The goal is still to increase the I/O buf size as this is a strong CPU load reducer (when from 8% to 2% on Built-in output on my MBP).

But anyway, there is still the fallback on "no increase" if clicking is still present...

 

Adyc & RHA: can you send me the debug logs so I get more info on your DAC ?

 

[damien78]

It is to provide access to iTunes database (readonly) from Audirvana, with a UI close to iTunes library browser.

In addition FLAC and other files from folders other than iTunes' will be included.

Remote control will be another challenge where I'm not sure (technical as well as legal reasons) Apple Remote App can be used. Thus uPnP will be the best other solution.

 

[damien78]

John: Thanks for your comment!

 

For your occasional gap, it may be explained by the RAM amount available.

The reason may be in this case that OSX begins to swap out the buffer that has been used because the player was paused for a while.

So it needs to reload it from disk and it is not instantaneous, thus the shutter when restarting playback.

 

[damien78]

New release 0.2.0 now includes background tracks loading.

This makes sample rate (up)conversion usable, as the long latency before playback start is now gone.

Sample rate converters used: Apple SRC for ALAC & compressed formats (setting to master quality), libSampleRate for FLAC, WAV & AIFF (setting to Sync Medium quality, max was too slow).

Note that sample rate conversion happens during sound playback and increases the CPU load. It thus may impact SQ during the load operation.

 

Also I prepared for split load when the allocated mem buffer is too small to load the entire track. It now loads as much as it can of too long tracks. Note that the playback will pause at the end of the loaded part for now. This is normal behavior until I implement the remaining of split load.

 

And I maxed the IO buffer size used (when option is selected) to a value that is a power of two. Can those who have DACs that showed clicking with this max buffer size option test it again ?

 

[damien78]

Both parameters are set to max quality: kAudioConverterSampleRateConverterComplexity to Master

kAudioConverterSampleRateConverterQuality to Max.

 

And it's still fast enough for realtime!

So I'm wondering if I'll not replace libsamplerate by Apple SRC for FLAC,AIFF & WAV also. Or offer choice.

 

What are your thoughts on compared quality of these two SRC ?

 

[damien78]

John: Is it for any kind of track or for some specific ones (duration, file type (ALAC, FLAC, AIFF, ...)) ?

 

[damien78]

Is there any sample rate conversion happening with those tracks ?

And is the loading progress bar still displayed ? It should disappear after load is complete.

 

Damien

 

[damien78]

I've issued an update with fixes for these two issues:

[*]Oversampling was setting incoherent file and DAC sample rates

[*]Workaround for CoreAudio underestimation of file length that lead to a pause at end of some tracks

 

Tell me if this fixes it on your system too.

 

Damien

 

[damien78]

John: With 1GB of mem, the audio buffers are likely to be swapped to disk as the OS is fighting to get available RAM. (On my MBP, I already have 764MB used by kernel stuff).

To maximize SQ, Audirvana loads completely the fully decoded (and sample converted) audio tracks in RAM in a double buffer. That is both the currently playing, and the next track are loaded at the same time. And this ensures gapless playback all the time.

So the realtime playing process only needs to read data in RAM to send it to the DAC. Period.

But it expects the data to still be in RAM.

Other players like iTunes or AyreWave use a temporary rotating buffer in an additional thread to cache in advance the data to be read, and smooth the potentially long data accesses (e.g. reading back from hard drive swapped buffer pages).

In your case, I'm sorry, but you'll need to get more RAM.

 

Damien

 

[damien78]

I've implemented an "emergency reload/unwswap" mechanism to force reloading in ram the remaining data of the currently playing audio buffer at the first cpu overload issue.

It's currently in svn, and it'll be in next release I'll make when I'll have completed the debugging of background playlist population (adding long list of tracks), and .m3u playlists load/save.

 

Soundscape & seta: you'll tell me if this fixes your issues.

 

Damien

 

[damien78]

Clay, I'm not using any code from Stephen Booth players. The only things we share are some opensource libs like taglib for reading some metadata, and the one to handle the Apple IR Remote.

 

In fact we use different load & playback concepts:

[*]AyreWave (when in memory play) load the file to mem, and uses a background thread to complete audio formatting and fill a small rotating buffer the realtime I/O thread will read from.

[*]Audirvana completely loads/decode/sample rate converts the audio track in a large buffer before starting playback (or does it in background at very beginning). The realtime I/O thread simply reads from this buffer without performing any other operation. So CPU load is minimized during playback. "Pure full memory play". And the next track to play is loaded in advance in another buffer to ensure gapless playback. The main caveat of this concept is that it needs more ram and may be defeated by swapping. That's why I'm currently investigating strategies to force the needed data to be in RAM when needed.

 

Clicking (for Audirvana) was due to some DAC drivers not liking I/O buffers of non power of two size.

 

BTW, this means whatever the lossless file format, the playback should be exactly the same (all decoding done before).

I'll be interested to get feedback from people who heard clearly audible differences between AIFF, WAV, ALAC or FLAC with other players.

 

Damien

 

[damien78]

Jud, thanks a lot for your comments .

I must also say that I really appreciate the courtesy and constructive discussions of this forum. And BTW, I have to thank Chris for it, as this is this very forum that made me discover that with a computer and a good DAC I could have much better results than with a high-end CD player for the same budget!

 

yes, SSD must lessen greatly the impact of swapping as it will reload much faster data in RAM. But Audirvana's concept is to avoid need for SSD, and get disks to spin down during playback to limit electromagnetic interferences.

 

Anyway, I'll keep looking at strategies to defeat swapping.

 

Damien

 

[damien78]

Not having a DAC 202, one way I tested Audirvana for bit transparency (but maybe it's not 100% correct?) was to play a DTS 16/44.1 file (demos available on the net) using SP/DIF output to my A/V receiver and check it was actually playing 5.1 DTS signal.

 

Damien

 

[damien78]

New build uploaded (rev 0.2.2) that mostly brings the convenience feature to add track folders to the playlist.

 

Changelog:

[*]Opening/dropping of track folders/li>

Background tracks insert into playlist

[*]Fast recovering from CPU overload (scan the remainings of the audio buffer to force it to be unswapped back to RAM)

 

Playlist load/save is next!

 

[damien78]

Lars & 4est: It seems there quite a segmentation here, and I'll be very happy to discover what makes the difference on very high end systems, while there is very positive feedback on more common systems with lower resolving power.

 

From the feature list, the main point Audirvana is lacking is the so-called Integer Mode.

This may be the reason as it enables the DAC driver to work in a more optimized mode:

1) No need to deal with the overhead of a mixing buffer

2) No additional format translation (though maybe less expensive than the mixing buffer)

 

But I don't have access to such a DAC with Integer mode to develop & test it...

 

[damien78]

What you get by doing a checkout of svn is the source code. So you need to build it using xcode afterwards.

With xcode installed, open the audirvana.xcodeproj.

Select the release version to build, and "build and run".

 

And the next step is ... to work on the code!

 

[damien78]

I've uploaded release 0.3.0 (0.3a) that implements:

[*]Playlist load/save (m3u & m3u8)

[*]Open playlists & audio file by dropping them on Audirvana icon or from the Finder ("Open With...")

[*]Get album art image from folder.jpg (or cover.jpg) file in the audio file folder if none was present in file metadatas

 

Damien

 

 

[damien78]

Bob: You can set the maximum allowed RAM for audio buffer in the user prefs from 512MB to RAM-1GB, so up to 3GB for a 4GB system (or 7GB for 8GB one).

 

Damien

 

[damien78]

Hi be4,

 

What exactly are the alternating clicks, are they coming with "CPU over" warnings? Do you get music in between them ?

Can you PM me the debug info you'll get from the menu command in the Audirvana menu ?

 

 

Damien

 

[damien78]

Bonjour François,

 

Thanks a lot for your proposal and support!

I'll propose that we first check if the HiFace driver offers such an Integer mode.

For this, I'll make a small update to Audirvana (probably this WE) to add Integer mode detection in the Debug Info.

 

Cheers,

Damien

 

[damien78]

Sure, this can be implemented, though I'm not very familiar with passing messages to the running instance this way.

wgscott: have you implemented such a feature in a Cocoa app before ?

 

Or shouldn't a direct implementation of responses to some scripting commands be a better solution ?

 

Damien

 

[damien78]

SanFranShootr: what happens when you select the ProFire 410 in the user prefs ? Is it appearing as the preferred device after you hit the change button ?

 

If it's still not working, can you send me (by PM) the debug info (command in Audirvana menu) ?

 

Damien

 

[damien78]

I've posted a new release (0.3.1) that fixes a flaw in the CPU over recovery method that made it ineffective.

Can those who encounter such repetitive CPU over warnings check with this one if the repeating sequence is now drastically reduced ?

 

In addition, this release adds the detection of the audio stream modes that are available only in hog mode. It is displayed in the debug info when the command is run while playing audio.

 

francois: can you run this Audirvana>Debug Info... command when audio is playing and paste the debug log in a PM (in English or French BTW ) you send me ? That'll help me determine if the hiface is supporting Integer Mode.

 

Damien

 

[damien78]

Bonsoir François,

 

Reading the debug logs you've posted, the hiface doesn't have the integer mode, as its only virtual format is the standard 32bit float.

But the Halide Bridge offers a 24bit integer format.

 

Best,

Damien

 

[damien78]

wgscott: the character set may be the issue. The m3u format expect ISO Latin1 characters. Is there anything special about the file names of the tracks that are not loaded?

You may want to try using m3u8 that is coded in UTF8, and thus has less issues.

 

Damien