Hi miero, I'd like to really appreciate this quick update with my sincere salute to you. The new module worked quite well and the previous ring buffer error on the BBB/Botic/NAA has totally disappeared 🙂 as shown in the log below:
Code:
Jul 6 20:23:57 arm networkaudiod[498]: [/usr/sbin/networkaudiod] (498): ALSA engine started at: 22579200 (22579200)
Jul 6 20:23:57 arm networkaudiod[498]: [/usr/sbin/networkaudiod] (498): enter streaming mode
Jul 6 20:23:57 arm networkaudiod[498]: [/usr/sbin/networkaudiod] (498): ALSA engine running...
Code:
access: RW_INTERLEAVED
format: DSD_U32_LE
subformat: STD
channels: 2
rate: 705600 (705600/1)
period_size: 131072
buffer_size: 262144
access: RW_INTERLEAVED
format: DSD_U32_LE
subformat: STD
channels: 2
rate: 352800 (352800/1)
period_size: 88200
buffer_size: 176400
access: RW_INTERLEAVED
format: DSD_U32_LE
subformat: STD
channels: 2
rate: 176400 (176400/1)
period_size: 44100
buffer_size: 88200
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
498 root 10 -10 25112 13612 2668 S 37.7 2.7 10:10.72 networkaudi+
3 root 20 0 0 0 0 S 4.6 0.0 1:19.86 ksoftirqd/0
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
498 root 10 -10 19452 8828 2668 S 19.4 1.7 10:23.46 networkaudi+
3 root 20 0 0 0 0 S 2.0 0.0 1:21.45 ksoftirqd/0
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
498 root 10 -10 16792 6756 2668 S 13.0 1.3 10:28.32 networkaudi+
707 root 20 0 6832 2776 2328 R 1.9 0.5 0:01.73 topAgain many many thanks to miero, Miska, and of course to Ray for giving me a hint of BBB/Botic as NAA and to Russ and Brian for your fine products, Buffalo III, IIISE and Hermes/Cronus boards.
Regards,
BTW: with this larger buffer issues with 384kHz seems to be gone 🙂
I'm testing this configuration:
audio data -> resample to 384kHz -> volume -0.5dB -> low-pass brickwall 23kHz -> playback to ES9018 with OSF disabled
I'm testing this configuration:
audio data -> resample to 384kHz -> volume -0.5dB -> low-pass brickwall 23kHz -> playback to ES9018 with OSF disabled
Having applied miero's patch I'm currently listening to DSD512, upsampled by HQPlayer from PCM rips, on my BBB/Botic/NAA, feeding Buffalo IIIse/Legato. Sound is amazingly good. Good stuff miero.
Anyway, here's some evidence;
and these are the HQPlayer settings I'm using;
I have been listening for well over an hour and I have experienced only a few minor dropouts - is further tweaking of the buffer size worth considering?
I have also noticed an audible click when playback is started/stopped though it isn't bad and certainly not equipment damaging - there is no click transitioning between tracks.
Upsampling to DSD512 is certainly working my HQPlayer PC hard, all four cores are at about 70-75% - the Xeon processor benchmarks at around 8000. BBB CPU is at around 35-40%.
Networkaudiod niceness/priority is set as 'out of the box'
I have not experienced any dropouts with DSD256.
I have also reinstated my network router, replacing it with a direct cable connection between the HQPlayer PC and the BBB seemed to reduce the number of dropouts I was experiencing previously but now it seems to make no difference. The good thing is that means I can now use Muso to control HQP via a tablet.
So a very positive result with respect to DSD512 but the story with upsampled 384KHz PCM is less rosy; although I was able to get some playback it invariably degraded to a static-like noise. I tried various settings in HQPlayer but to no avail. Upsampled 192KHz PCM works perfectly. I'm enjoying the DSD playback too much at the moment but tomorrow I'll try to record what Networkaudiod is doing/reporting with 384PCM.
Thanks again miero and Jussi.
Ray
Anyway, here's some evidence;
and these are the HQPlayer settings I'm using;
I have been listening for well over an hour and I have experienced only a few minor dropouts - is further tweaking of the buffer size worth considering?
I have also noticed an audible click when playback is started/stopped though it isn't bad and certainly not equipment damaging - there is no click transitioning between tracks.
Upsampling to DSD512 is certainly working my HQPlayer PC hard, all four cores are at about 70-75% - the Xeon processor benchmarks at around 8000. BBB CPU is at around 35-40%.
Networkaudiod niceness/priority is set as 'out of the box'
I have not experienced any dropouts with DSD256.
I have also reinstated my network router, replacing it with a direct cable connection between the HQPlayer PC and the BBB seemed to reduce the number of dropouts I was experiencing previously but now it seems to make no difference. The good thing is that means I can now use Muso to control HQP via a tablet.
So a very positive result with respect to DSD512 but the story with upsampled 384KHz PCM is less rosy; although I was able to get some playback it invariably degraded to a static-like noise. I tried various settings in HQPlayer but to no avail. Upsampled 192KHz PCM works perfectly. I'm enjoying the DSD playback too much at the moment but tomorrow I'll try to record what Networkaudiod is doing/reporting with 384PCM.
Thanks again miero and Jussi.
Ray
Last edited:
Just for completeness I have just been checking out DSD256 and there are no clicks.
I should also have mentioned that, as it's late evening here, I am doing my listening with good quality headphones. SQ is really good, smooth (not bland!) but dynamic and great detail.
Ray
Great to hear that things are now working! 🙂
The DAC output should be muted for about 50 ms during playback start/stop. And for example some USB interfaces correctly control MUTE output signal for this.
This is because DSD data is stateless unlike PCM. So it will take certain amount of bits for the DAC to settle to a sensible value when data begins to flow. Same goes when the data abruptly stops. Sometimes, in worst case, PCM-oriented interface will spit out series of 0-bits at the end which will drag the output pretty quickly to the negative rail...
As long as HQPlayer is playing (or paused), it keeps the bitstream flowing and thus such shouldn't happen (although ESS Sabre has automatic DSD silence detection and may take some actions).
The DAC output should be muted for about 50 ms during playback start/stop. And for example some USB interfaces correctly control MUTE output signal for this.
This is because DSD data is stateless unlike PCM. So it will take certain amount of bits for the DAC to settle to a sensible value when data begins to flow. Same goes when the data abruptly stops. Sometimes, in worst case, PCM-oriented interface will spit out series of 0-bits at the end which will drag the output pretty quickly to the negative rail...
As long as HQPlayer is playing (or paused), it keeps the bitstream flowing and thus such shouldn't happen (although ESS Sabre has automatic DSD silence detection and may take some actions).
Jussi, our last posts were at just about the same time; I posted an update about the clicks, which I am not experiencing with DSD256?
Ray
Ray
I'm not sure why it would make difference, unless starting DSD512 causes some drop-outs at the beginning. Some people say that Sabre is limited to DSD256, but only think I've seen is that they specify that MCLK must be at least 3x the DSD BCLK (they need three clock cycles for the 3rd order filter).
Hi miero, as I wrote above, I thought the xrun issue has gone. Today, however, I noticed it does still occur during playing upsampled DSD512 sources, though not quite a few times: only once in a half hour during play as show in the log below:
Code:
Jul 7 19:37:39 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA engine stop request...
Jul 7 19:37:40 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA engine stopped
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): start 24576000/1/2 [dsd]
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): Set channels: 2 (2)
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): Set sampling rate: 24576000 (24576000)
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA engine starting...
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA channels: 2 - 8
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA active channels: 2
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA number of periods: 2
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA period times: 5 - 170667
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA period sizes: 4 - 131072
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA period time: 170666
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA period size: 131072
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA engine started at: 24576000 (24576000)
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): enter streaming mode
Jul 7 19:37:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA engine running...
Jul 7 20:14:25 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA attempting X-run recovery...
Jul 7 20:14:25 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA attempting X-run recovery...
Code:
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): start 11289600/1/2 [dsd]
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): Set channels: 2 (2)
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): Set sampling rate: 11289600 (11289600)
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA engine starting...
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA channels: 2 - 8
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA active channels: 2
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA number of periods: 2
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA period times: 11 - 371520
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA period sizes: 4 - 131072
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA period time: 250000
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA period size: 88200
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA engine started at: 11289600 (11289600)
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): enter streaming mode
Jul 7 20:19:42 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA engine running...Here is another issue. Though this is quite rare, I encountered another kind of xrun error that might be associated with RT kernel as shown in the log below:
Code:
Jul 7 17:23:57 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA engine running...
Jul 7 17:55:52 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA attempting X-run recovery...
Jul 7 17:55:52 arm kernel: [ 3551.831048] sched: RT throttling activated
Jul 7 17:55:54 arm networkaudiod[502]: [/usr/sbin/networkaudiod] (502): ALSA attempting X-run recovery...Regards,
twluke, your findings reflect my own experiences with DSD512, just a few occasional dropouts, I too am wondering if another tweak of the buffer size might do the trick.
Are you hearing the clicks I reported?
Have you tried upsampling to 384KHz PCM?
Ray
Are you hearing the clicks I reported?
Have you tried upsampling to 384KHz PCM?
Ray
I hope it will do.
If this is meant for clicks on start and stop, the answer is yes but they seem okay for me 🙂 .
Yes, I did but only heard stuttering music sound mixed with some noisy background. BTW, the log messages showed no xrun error during it. Maybe limitation of BBB?
Well one more thing. After changing XO from 22.5792 to 45.184 on the Cronus board, I noticed it took more time for MCLK locking, independent on the filter selection on the side of HQP. I don't know why this happens.
So, I need more experiments for this new combination of BBB/Botic/NAA and Buffalo DAC for playing upsampled DSD512 sources, that has been causing a frenzy of excitation among these upsamplextremists (😉) pertinent to a forum of one particular chipless DSD DAC.
I'm curious, can you link to the forum?
I have been experimenting with the 'nodac' concept recently.
Ray
Very curious, I've just played PCM upsampled to 352.8KHz for about 45mins without any sign of the issues I had last evening - not a single glitch of any sort?
Just to add a little detail to my hardware setup, I'm using 'a.n.other' isolator/reclocker that is equipped with 90/98MHz crystek oscillators, these also provide the clocking to the BBB and to the BIIIse in full sync mode.
Ray
An externally hosted image should be here but it was not working when we last tested it.
Just to add a little detail to my hardware setup, I'm using 'a.n.other' isolator/reclocker that is equipped with 90/98MHz crystek oscillators, these also provide the clocking to the BBB and to the BIIIse in full sync mode.
Ray
This evening I've had a good listening session over a couple of hours. Source material is 16/44.1 and 24/48 FLAC rips, upsampled with HQPlayer to 352/384KHz PCM and 22/24MHz DSD (512). I've done lots of switching between 44.1/48 and PCM/DSD to see if I could induce any misbehaviour.
Firstly, my initial impressions of the sound quality at these high rates was reinforced, very natural and easy to listen, bags of low level detail and everything in its own distinct space. I'm experiencing one of those spells when you just want to keep going through your music collection.
Issues I've encountered have been minor;
I've heard enough to be convinced this route is worth sticking with, the minor issues I can live with and, hopefully, a little more tweaking will resolve the dropouts.
Anyway, it looks as though the BBB/Botic/NAA is pretty much there for DSD512 and PCM384 replay.
Ray
Firstly, my initial impressions of the sound quality at these high rates was reinforced, very natural and easy to listen, bags of low level detail and everything in its own distinct space. I'm experiencing one of those spells when you just want to keep going through your music collection.
Issues I've encountered have been minor;
- A few dropouts with DSD512 as previously reported
- On just a couple of tracks (PCM and DSD) I heard a low level static noise for maybe 10-20secs, which just faded away. On replaying the same tracks the noise was gone? Mostly silences between selections were silent but just occasionally there was a little background noise, again like static. Its entirely possible that this is unrelated to the BBB/Botic/NAA combo.
- All PCM replay was uninterrupted (by dropouts).
- The clicks on 'Start' and 'Stop' with DSD512 that I reported previously.
I've heard enough to be convinced this route is worth sticking with, the minor issues I can live with and, hopefully, a little more tweaking will resolve the dropouts.
Anyway, it looks as though the BBB/Botic/NAA is pretty much there for DSD512 and PCM384 replay.
Ray
Last edited:
(1-3) It is possible that data transfers in such high bitrates are not completed soon enough and that invalid (already played audio) data is being played. Or in the other words, it is not bit perfect, due to the slow CPU/data transfers.
Thanks miero. Any thoughts on investigating this? Might a low-latency RT kernel distribution help? At the moment I am using the standard Debian Stretch release for ARM and I'm not changing the niceness or priority of any processes.
Are you considering another patch to explore the optimisation of the buffer further?
That said, the issues I encountered were minor anyway and almost all playback was excellent and trouble free.
Cheers
Ray
Last edited:
Some more testing today but not quite so positive...
Until now I've only been listening with my headphones but I thought it was about time I moved to the main system; this consists of Transcendent 300B OTL amps and AllFun horns with Lowther EX3s so nice and revealing.
PCM, up to 384KHz, was trouble free and sounded really excellent, likewise DSD256. With DSD512 though, whilst it played and sounded OK, there was an audible static-like noise under the music all the time. I had heard this sort of noise before but it had faded away. The only change from previous listening (apart from, obviously, using the amps/speakers instead of headphones) was a much longer cat5 UTP Ethernet cable (I've previously been using a 1.5metre cat6 cable)?
Has anyone else had success with DSD512 with the ESS9018 DAC chip? I can't find anything explicit about the 9018 specs in this respect?
Anyway, the good thing is that the positives were very positive with great sound quality, smooth but detailed with an excellent sound stage and a great insight onto the performers playing/singing.
Ray
Until now I've only been listening with my headphones but I thought it was about time I moved to the main system; this consists of Transcendent 300B OTL amps and AllFun horns with Lowther EX3s so nice and revealing.
PCM, up to 384KHz, was trouble free and sounded really excellent, likewise DSD256. With DSD512 though, whilst it played and sounded OK, there was an audible static-like noise under the music all the time. I had heard this sort of noise before but it had faded away. The only change from previous listening (apart from, obviously, using the amps/speakers instead of headphones) was a much longer cat5 UTP Ethernet cable (I've previously been using a 1.5metre cat6 cable)?
Has anyone else had success with DSD512 with the ESS9018 DAC chip? I can't find anything explicit about the 9018 specs in this respect?
Anyway, the good thing is that the positives were very positive with great sound quality, smooth but detailed with an excellent sound stage and a great insight onto the performers playing/singing.
Ray