HQ Player

[Miska]

I haven't been able to solve this problem, (which is very annoying to say the least).

Tried with a licensed version in MacBook (Mavericks) and now with a toshiba netbook (W8) and the problem persists.

Whenever the player try to read from the NAS I get noise/dropouts, if played locally works as a charm. But not being able to use the library is frustrating.

 

It is hard to say where the problem is, because there are many different possibilities.

 

I've been using SMB share a lot for my content, since I don't want to duplicate it to all test machines...

 

On iMac 27 + Mavericks things work fine when I use "smb://xxx" URI to mount the share, but not if I use "cifs://xxx". This machine is connected using gigabit wired ethernet.

On Windows Vista, 7, 8 and 8.1 things work fine, without mounting the share by using \\server\share name for the library. Connection type varies from machine to another, including 100 Mbps / gigabit wired ethernet and 802.11g/n WLAN connections.

 

SMB server is Core i5 machine running Linux and Samba 4.x with stack of encrypted SATA3 HDDs (7200 rpm).

 

Transfer speeds when copying files are around 35 megabytes per second (IOW, no jumbo-frames configured).

[Miska]

No problem in upgrading to Yosemite with HQP, right?

 

I've tested HQPlayer 3.5.1 on Yosemite (MacBook Air) and everything I've tested have been working fine. Only thing Yosemite initially broke was drag-and-drop, but I've fixed that in 3.5.1...

[Miska]

Never mind I turned off direct SDM in DSDIFF settings and bingo. Forgot it can't be bit perfect when up sampling PCM to DSD.

 

Turning off "Direct SDM" allows you to resample DSD to another DSD rate or to apply other DSD processing on it. It doesn't have effect on PCM to DSD conversion, only for DSD sources.

 

Is this with HQPlayer 3.5.1? Earlier versions had some problems with DSD rate switching. I have tested DSD rate switching between different DSD rates, including DSD256, "Direct SDM" enabled with iFi DACs on all platforms and things are working fine for me.

 

There's some firmware bug in iDSD Micro which makes it go confused and stop working after some period of time (even without using it at all), so I need to unplug and replug the USB to get it back to sane state. I haven't got any response from iFi/AMR on this topic...

[Miska]

I am on 3.5.1 revision also. I can upsample PCM all the way to DSD512, but i cannot get the DSD sources up sampling to work with my ifi iDSD Micro with no success. Are you saying for iDSD, "direct SDM" has to be enabled? What is the recommended settings? Thanks for the support.

 

There are no clear recommended settings as it depends on situation and preferences.

 

If you'd like to upsample DSD to DSD, you need to disable/uncheck the "Direct SDM" setting to enable SDM DSP engine. When "Direct SDM" is off, same DSP functionality is available for DSD sources as is for PCM sources.

 

The logic is quite complex, but there is logic...

A.1) Output mode is PCM, filter is set to "none" and "Direct SDM" is enabled: Output rate follows source rate, there's never rate conversion. Volume, speaker processing and convolution is available for PCM sources. DSD is played bit-perfect without any processing (given that DAC supports DSD).

A.2) Output mode is PCM, filter is set to something: Selected output rate is obeyed and everything plays at given rate as PCM.

B.1) Output mode is SDM and "Direct SDM" is enabled: PCM is converted to given DSD rate. DSD is played at source rate bit-perfect without any processing.

B.2) Output mode is SDM and "Direct SDM" is disabled: PCM and DSD are converted to given DSD rate. Volume, speaker processing and convolution is available for both PCM and DSD sources.

 

I hope this clarifies how the logic (is supposed to) work in version 3.5.1.

 

When playlist transport is used and a conflict between given instructions and capabilities is found, playback stops at that point.

[Miska]

So you're saying that every time I add new albums to each location the correct procedure is to add tree again like it was the first time?

 

Yes, it'll discover the previously unknown content, but won't touch the already known ones. You can also point it to look at some place closer to the added content. So for example if you added just couple of albums of single artist, you can point at the artist folder. Narrower scope makes the operation faster.

 

If some metadata inside files is a bit off, you can correct that in the library view. These changes are only stored in HQPlayer's library data, the source files remain as they are.

 

I'm for example storing Channel Classics content in one folder and content from highresaudio.com in another folder. So when I buy new albums from either, I just point "Add tree" to the corresponding shop's folder. Library views always show an aggregated view of how ever scattered content, so this structure is not visible there.

[Miska]

poly-sinc

 

You can experiment with different variants on the poly-sinc to find one you prefer the most. The ones that end in "-2s" are significantly lighter in terms of CPU load. But at DSD64 rates load shouldn't become an issue anyway.

 

DSD5 (what is optimum here?)

 

With the latest 3.5.1 version of HQPlayer, default is ASDM5 which I also recommend for Loki.

 

2822400

 

You could also try with the "-2s" filter variants to 3.1 MHz which is also supported by Loki. Some people prefer to stay at 2.8 MHz for 44.1/88.2/176.4 content and 3.1 MHz for 48/96/192 content, but technically it doesn't make much difference. I would use 3.1 MHz always...

 

I am also thinking of bying a full monty dac...Mytek192 or Oppo HA 1...any advice?

 

Mytek is not good choice for Linux, because you'd need to build drivers yourself. I have not tested recently, but TEAC UD-501 should work on Linux and offers excellent price/performance ratio. For Sabre-based DACs, you could look at Resonessence Labs products.

[Miska]

What is the minimum system requirement to perform PCM upsampling (44->192) ? Would it work on CAPS v3 (intel dt2800) ?

 

44.1k to 192k is really light with the poly-sinc filter family. Also 352.8/384k should work on most CPUs without problems.

 

So I wouldn't expect problems on that front. Looking at specs of the Atom N2800 I believe it should do just fine for that.

[Miska]

But it could be also that for some reason on Yosemite on my 3rd party SSD cannot operate on a non-journaled drive?

 

I didn't know about that, but I know Apple disabled TRIM for 3rd party SSDs on Yosemite. So eventually a 3rd party drive will become very slow...

[Miska]

I set the buffer time to 50 ms and then to 100 ms, but it did not help. I am now trying the highest setting (250 ms), but at this point I have little hope that this will solve the issue. Any other suggestions? Miska?

 

I'm not sure what could be the source. Buffer time setting doesn't have effect on CoreAudio.

 

There are practically no changes on CoreAudio implementation recently. There are some changes in the DSP engine, but these are common to all platforms so any problems there should appear on all three platforms. One bigger change since 3.4.1 was Xcode update from Apple (broke drag-and-drop support together with Yosemite).

 

One note, if you are upsampling to DSD, do not enable "Pipeline SDM" setting unless you really need that (slow multicore CPU like AMD A6).

[Miska]

Here's load profile on my iMac 27 with Mavericks playing to DSD128 from "smb://" mounted network server using the built-in UAC driver to Resonessence Labs HERUS connected to wired keyboard's USB2 hub port... No drop-outs so far.

 

[Miska]

Here's load profile on my iMac 27 with Mavericks playing to DSD128 from "smb://" mounted network server using the built-in UAC driver to Resonessence Labs HERUS connected to wired keyboard's USB2 hub port... No drop-outs so far.

 

I left this playing overnight with repeat enabled, now it is still playing fine without issues. We have one MacBook Air with Yosemite in the family, I'll borrow it and do the same test with same DAC and see if things still work as reliably.

 

One suspect in these problems is always AppNap, but usually when it comes to play the stuttering becomes constant and the entire playback collapses.

 

Here are instructions how to disable AppNap completely:

How to disable App Nap system-wide on OS X Mavericks - CNET

 

(for the record, I have not disabled it)

[Miska]

I've been now playing on MacBook Air with Yosemite, same DAC. Playing from "smb://" mount over WLAN there are dropouts, because for some reason the WLAN is pretty slow (afterwards copying the album to local SSD took quite a while). But when playing from the internal SSD storage the playback is still stable after two cycles.

 

Reason I used this DAC for the testing is that I know it being robust on Linux and OS X with the built-in UAC drivers. With the iFi DACs (especially Micro) I know the firmware may/will eventually start acting up and needs unplug/replug cycle to recover.

 

Maybe there have been changes on how the asynchronous USB packet management works, at least I know it has been subject to tuning on Linux kernel recently. So maybe something similar has been ongoing on OS X too. Interoperability depends on UAC2 implementation on both sides.

 

 

 

Note! AppNap usually activates when window goes completely hidden, so in case you have problems, please take a note if it happens in relation to the player window being visible or not. This information could help...

[Miska]

The problem is that all happens within one sample. Even with interrupt and fast MCU it is often not possible to catch this stream change before it has put a full-scale pulse through the system, as the this pulse happens at the instant the stream

 

For this reason, DAC must have enough RAM FIFO buffer and thus look-ahead for the DoP marker, so that it knows already 200 ms before the sound comes out, what kind of data there is to come and thus have enough time to react before the data reaches DAC chip.

 

Many DACs don't manage with this and thus have a problem. For example iFi iDSD Nano has noisy switch over even with native DSD.

 

For example HQPlayer when it sees that there's a problem, can go back in time and recalculate number of samples, even multiple times to achieve a good solution that actually comes out... With fast enough processor, even one sample feels like a very long time and you can do many different re-evaluations and decisions within that time. When the processor runs at 4 GHz, a sample at 2.8 MHz interval is pretty slow rate (more than thousand clock cycles to spare)...

 

But the problem with especially iFi iDSD Micro is some firmware bug that the device stops responding to USB messages after some time and stop working altogehter. Completely bust until re-plug.

[Miska]

followed your tip...concero arrived yesterday...all evening listened to cd rips and all kinds off dsd samples...amazing combination your player and the concero...I am very pleased. btw are the settings ok?

 

native/upsampled to DSD128 is the way I liked the most...and probably the only way I will use it...

 

Looks good, for PCM you could set "384000" as rate limit in order to default to maximum PCM rate supported by the DAC. Which I believe is 352800 for the Concero HD.

[Miska]

The problem is that all happens within one sample. Even with interrupt and fast MCU it is often not possible to catch this stream change before it has put a full-scale pulse through the system, as the this pulse happens at the instant the stream changes.

 

And for the record, this never happens with HQPlayer...

[Miska]

Miska - are you saying that the iFi iDSD Nano and Macro do not have any pop or click issues when being played to by HQP? This would be great as I have a friend that wants to go down the HQP DSD route but he can't justify spending much money on another DAC (he bought a PCM only DAC about a year ago).

 

I just meant that with HQPlayer the change never happens on-the-fly. At least with Nano the switch tends to always make noises. I don't remember how well Micro does it, but at least I have not paid special attention to it, I'll check it again.

 

TEAC UD-501 switches completely silently for me and it is same price category as the iDSD Micro.

[Miska]

I wonder if Miska has tested HQPlayer 3.5.1 at DSD512? I would point out that this is not a big deal in my life as HQPlayer sounds wonderful at DSD256 but still it is curious that foobar works and HQPlayer does not at DSD512.

 

Yes, I have tested it.

 

Maybe foobar does things same way as DAC chips do internally. But I specifically wanted to avoid that for quality reasons. So most likely the difference is in algorithm complexity, HQPlayer having much more complex algorithm.

[Miska]

I have checked and it is not a matter of cpu use on my I7 computer. In foobar at DSD512 the usage is at around only 10-12%. I notice an increase to more like 25% with HQPlayer but still reasonable. Any suggestions?

 

The overall load doesn't tell much yet. First open Task Manager and then from there, open Resource Monitor and check that none of the CPU cores exceed about 90% load level. If some cores max out and others idle, you can increase parallelism by checking the "Pipeline SDM" setting in Settings dialog. This will increase overall load quite a lot, but more evenly distributes the load. (note that only real CPU cores help, the core doubling provided by HyperThreading doesn't help with this kind work load at all)

 

What is your "Buffer time" setting? You could try changing it to 100ms.

[Miska]

I did not see any cores maxing out but I only used it briefly.

 

Exceeding 75% level on any core increases risk for drop outs. On the CPU tab you can see per-core loads graphs. When the load wanders around 90% the dropouts begin.

 

Every time output sampling rate is doubled, CPU load grows more than double.

 

I would not even have raised the question if it was not for the fact that foobar plays upsampled pcm to DSD512 without any problem. I will play with it tomorrow and report back. I would expect and I7 based computer running at 4ghz to be more than enough for the task.

 

It should be OK with the "-2s" category of poly-sinc filters.

 

With iDSD Micro, generally best option is to leave "Buffer time" as "Default" and then launch ASIO control panel from Tools-menu. And there select "Extra safe" as streaming mode and "8192" as buffer size.

[Miska]

What exactly pipeline SDM checked does?

 

It splits work into more CPU cores, but it happens in such place that there is also considerable overhead for doing so. Thus it should be used only when there are number of real cores (four or more) and some of those cores max out and results in drop outs.

 

In order to get native DSD reproduction, the SDM settings must be set to none, correct?

 

When "SDM Pack" is set to "none", then native ASIO DSD is used on Windows/Mac when available, or native ALSA DSD on Linux. When it is set to "DoP", then it is override and DoP is always used.

 

I did that, but in playlist mode the tabs above it only showed PCM?

 

If the right most drop-list shows only PCM, then native DSD support has not been detected. Note that with CoreAudio on Mac and WASAPI on Windows, only way to do DSD is to use DoP.

[Miska]

No ASIO drivers from the manufacturer (MSB) of my dac, unfortunately.

So does this mean that I can't play native DSD with hqplayer?

 

If it supports DoP you can, but it means 33% - 50% more data to send to the DAC and that there's no auto-detection of the DSD capability.

[Miska]

It supports DoP, so if i want to play native dsd should i check DoP in settings?

 

Yes, exactly, select "DoP" as "SDM Pack" method.

 

If you want DSD sources to play bit-perfect, keep "Direct SDM" selected in DSDIFF/DSF Settings (default). If you'd like to upsample or otherwise process DSD sources, disable this setting to enable DSP processing. For PCM sources DSP processing is always available.

[Miska]

With mac/yosemite.

 

What kind of content are you trying to play and what are the settings? Usually, especially with NAA, it is due to too high CPU load on the player computer. But there are some other possibilities too, one is App Nap, another is slow WiFi (I have experienced this on MacBook Air).

 

AppNap is more likely to become problem when playing to NAA, because CoreAudio is not used and thus OS X thinks the application is not doing anything critical and can be put to sleep.

[Miska]

Forgot to say I'm using an IFI micro DSD DAC.

 

Yes, DSD256 on that DAC is the expected result. I will do necessary updates sometime soonish to update that capability to DSD512.

[Miska]

That's great news Tony. A number of us have been waiting for this. Which DAC are you using? I have the exasound e22, which is DSD256 capable and I will try it with the SOTM SMS-100 tomorrow. It could be that the latest software for the SMS-100 includes the update to ALSA, which is supposed to provide DSD support up to DSD256 without the need for custom drivers.

 

exaSound DACs will require a custom Linux driver, which is on the way...