Support for Botic Linux driver

[twluke]

Or perhaps I'm misreading your table and you're upsampling DSD64 to DSD256 in the first set of results?

Yes, that is the correct interpretation of my table. DSD64@5.6448 means that the bit rate of a DSD64 source is up-sampled to 5.6448 by HQP as shown by the picture below. Sorry for this confusion.

I have some DSD256 recordings that I plan to load onto the BBB and play with MPD but I'm convinced that'll work perfectly.

Ray

Yes it does work. MPD on Botic-BBB can play DSD256 sources without any problems.

Regards,

 

[francolargo]

Hi Ray,
...not to 'pry', but just wishing you the best possible success...
If I recall correctly, you said networkaudiod runs happily along at about 20% CPU but occasionally spikes up to ~75%. In my experience pushing the BBB CPU with DSP programs, that higher CPU load per-se should not be a problem. I've only had 'competition-type' dropouts (sometimes from the process 'systemd') when reported CPU load is about 90%. So could the gremlin be in the network? Is the source network connection for the NUC the same as BBB? What if you ran networkaudiod at a priority that is just below the system IRQs and then look for any other processes whose CPU use increases on either end of the network? [For my BBB, this would be 'chrt -f 45 <networkaudiod's start command>'] I will eventually use a Mac for HQP, so I could open a terminal on it and also run 'top', or there are GUI system programs to show process and network activity. There must be similar monitoring in Win10...

Best,
Frank

 

[nautibuoy]

Hi Ray,
...not to 'pry', but just wishing you the best possible success...
If I recall correctly, you said networkaudiod runs happily along at about 20% CPU but occasionally spikes up to ~75%. In my experience pushing the BBB CPU with DSP programs, that higher CPU load per-se should not be a problem. I've only had 'competition-type' dropouts (sometimes from the process 'systemd') when reported CPU load is about 90%. So could the gremlin be in the network? Is the source network connection for the NUC the same as BBB? What if you ran networkaudiod at a priority that is just below the system IRQs and then look for any other processes whose CPU use increases on either end of the network? [For my BBB, this would be 'chrt -f 45 <networkaudiod's start command>'] I will eventually use a Mac for HQP, so I could open a terminal on it and also run 'top', or there are GUI system programs to show process and network activity. There must be similar monitoring in Win10...

Best,
Frank

Hi Frank

The networks are identical for the NUC and the BBB devices, I just switch the Ethernet cable from one to the other.

I think the CPU peaks are a reaction to the dropouts, i.e. an affect rather than the cause, kind of playing catch-up.

Next I plan to make a direct network connection from the HQPlayer PC to the BBB, eliminating the router.

I also plan to use BBB/Botic without NAA to see how it works with a DSD256 file (I'll use UPnP to 'send' the file).

 

[nautibuoy]

I'm currently running BBB/Botic/NAA via a direct cable connection to the NIC in the HQPlayer PC, currently with no change to the niceness or priority of the networkaudiod process - so far (about 10-15mins listening, 44.1KHz/16bit PCM upsampled to DSD256) there have been no dropouts. I'm listening with headphones but the sound quality is very good.

Network connection is operating at 100Mbps, obviously dictated by the BBB. With the NUC, and using the router, operation is at 1000Mbps.

Ray

 

[twluke]

I'm currently running BBB/Botic/NAA via a direct cable connection to the NIC in the HQPlayer PC, currently with no change to the niceness or priority of the networkaudiod process - so far (about 10-15mins listening, 44.1KHz/16bit PCM upsampled to DSD256) there have been no dropouts. I'm listening with headphones but the sound quality is very good.

Hi Ray,

Thank you for your latest report. Following my previous experiment of BBB/Botic/NAA on the HQP running on Ubuntu, this time, encouraged by your comment, I checked the capability of this conduit from the HQP running on my MacBook (13-inch, Mid 2012, 2.5 GHz Intel Core i5) with my B3SE as a connecting DAC.

To my surprise, the HQP on my MacBook could almost completely play 44.1/16 flac sources upsampled to DSD256 as shown below, even permitting the situation is partly dependent on the filter selection. Only a few unlocks per minutes which were little annoying on listening to music. I think the B3SE is also greatly contributing to this result.

As shown by another picture below, the CPU usage on the MacBook is about 197%, indicative of about 40% usage per core, while the usage on BBB is about 20%: that would be not bad.

The results of mine are quite suggestive of the capability of BBB/Botic/NAA being able to deal with these Red Book sources upsampled higher to DSD512 as long as the HQP is running on a machine with more powerful CPU (not necessarily i7 6700K).

 

[nautibuoy]

Hi Ray,

Thank you for your latest report. Following my previous experiment of BBB/Botic/NAA on the HQP running on Ubuntu, this time, encouraged by your comment, I checked the capability of this conduit from the HQP running on my MacBook (13-inch, Mid 2012, 2.5 GHz Intel Core i5) with my B3SE as a connecting DAC.

To my surprise, the HQP on my MacBook could almost completely play 44.1/16 flac sources upsampled to DSD256 (upsampled from 44.1/16 PCM) as shown below, even permitting the situation is partly dependent on the filter selection. Only a few unlocks per minutes which were little annoying on listening to music. I think the B3SE is also greatly contributing to this result.

As shown by another picture below, the CPU usage on the MacBook is about 197%, indicative of about 40% usage per core, while the usage on BBB is about 20%: that would be not bad.

The results of mine are quite suggestive of the capability of BBB/Botic/NAA being able to deal with these Red Book sources upsampled higher to DSD512 as long as the HQP is running on a machine with more powerful CPU (not necessarily i7 6700K).

I have a reasonably powerful workstation running HQPlayer (Intel Xeon E3-1240 @ 3.30GHz, benchmarks at around 8000) so I gave DSD512 a try and it almost works; it plays fine for maybe 10secs at a time but is interrupted by a machine gun like sound. HQPlayer CPU loading was around 60% (on all four cores) and network load was close to 50% on the dedicated 100Mbps Ethernet connection. I neglected to note the load on the BBB as I stopped playback quickly because of the noise.

 

[yanpetr]

My DAC for example, wadia and many others in the winding on the beaglebone via the SPDIF or the track change – emit an unpleasant tone (click)
For example, on USB it ONLY happens with the change of frequency from 44 to 48.
Volumio on beaglebone via USB – no clicks.
Can this be fixed in the botic driver ?

 

[Signalyst]

I have a reasonably powerful workstation running HQPlayer (Intel Xeon E3-1240 @ 3.30GHz, benchmarks at around 8000) so I gave DSD512 a try and it almost works; it plays fine for maybe 10secs at a time but is interrupted by a machine gun like sound. HQPlayer CPU loading was around 60% (on all four cores) and network load was close to 50% on the dedicated 100Mbps Ethernet connection. I neglected to note the load on the BBB as I stopped playback quickly because of the noise.

Is that with Pipeline SDM enabled and -2s filters, such as poly-sinc-short-2s? I think it could actually work...

 

[nautibuoy]

Is that with Pipeline SDM enabled and -2s filters, such as poly-sinc-short-2s? I think it could actually work...

These are the settings I used;

I also tried some DSD256 recordings as the starting point, upsampling to DSD512, but the results were similar.

 

[twluke]

These are the settings I used;

I think the bit rate of 5.6448 x 4 (= 22.5792) instead of 24.576 might work.

 

[nautibuoy]

I think the bit rate of 5.6448 x 4 (= 22.5792) instead of 24.576 might work.

As I mentioned to you before, the 'Auto rate family' check box means HQPlayer will automatically select the appropriate integer multiplier based on the source material rate.

With the settings as they are, if the source is 44.1KHz then HQPlayer will set the DSD rate to 22MHz, if the source is 48KHz the DSD rate will be set to 24MHz.

Upsampling 16/44.1 PCM files, HQPlayer does indeed automatically set the DSD rate to 22MHz with these settings.

 

[twluke]

I have a reasonably powerful workstation running HQPlayer (Intel Xeon E3-1240 @ 3.30GHz, benchmarks at around 8000)

In order to evaluate the potential capability of BBB/Botic as an NAA for HQP, I assembled a PC with a core i7 6700k and 16GB DDR4 SDRAM this week. The HQP was a 3.1.3 evaluation version running on Windows 10 and the NAA of 3.4.0 running on Boticized debian stretch (4.5.0-botic7-rc1).

so I gave DSD512 a try and it almost works; it plays fine for maybe 10secs at a time but is interrupted by a machine gun like sound. HQPlayer CPU loading was around 60% (on all four cores) and network load was close to 50% on the dedicated 100Mbps Ethernet connection.

Like you, I confirmed BBB/Botic can really deal with DSD512, though often hampered by this machine-gun-like sound lasting a few seconds, during which the log file showed an error message like below:

Jun 29 16:40:09 arm networkaudiod[537]: [/usr/sbin/networkaudiod] (537): ALSA attempting X-run recovery...

It may suggest that this noisy sound is deriving from a ring buffer error related to ALSA XRUN, probably an overrun error.

I noticed a similar error message even on playing DSD256 occasionally, in which the error appeared as a signal drop instead of buzzy sound: probably indicative of an underrun error.

I tried to change [FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica]/proc/asound/card0/pcm0p/sub0/prealloc trying to manipulate the default setting but the value remained fixed.

Also I noticed that in /proc/asound/card0/pcm0p/sub0/[/FONT][/FONT][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica]hw_params [/FONT][/FONT]the period_size and buffer_size remained the same whether the source is DSD512 or not as shown below:

DSD128
access: RW_INTERLEAVED
format: DSD_U32_LE
subformat: STD
channels: 2
rate: 176400 (176400/1)
period_size: 8192
buffer_size: 16384

[/FONT][/FONT][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica]DSD256
[/FONT][/FONT]access: RW_INTERLEAVED
format: DSD_U32_LE
subformat: STD
channels: 2
rate: 352800 (352800/1)
period_size: 8192
buffer_size: 16384

DSD512
access: RW_INTERLEAVED
format: DSD_U32_LE
subformat: STD
channels: 2
rate: 705600 (705600/1)
period_size: 8192
buffer_size: 16384[/FONT][/FONT]

So it's my impression that the issue may be associated with the current build of networkaudiod and the BBB/Botic will be basically work as a solid NAA. The situation may change in a future version of networkaudiod.

I neglected to note the load on the BBB as I stopped playback quickly because of the noise.

In my case, the BBB/Botic NAA could complete playing music anyway, smoothly moving on to the next track. The CPU load by HQP with DSD512 was about 22% with 45-46Mbps(44.1k) rate and the one by networkaudiod on BBB was either 28-38% with no error or 85% with xrun error.

 

[Signalyst]

Also I noticed that in /proc/asound/card0/pcm0p/sub0/[/COLOR][/FONT][/COLOR][/FONT][/SIZE][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica]hw_params [/FONT][/FONT]the period_size and buffer_size remained the same whether the source is DSD512 or not as shown below:

...

In my case, the BBB/Botic NAA could complete playing music anyway, smoothly moving on to the next track. The CPU load by HQP with DSD512 was about 22% with 45-46Mbps(44.1k) rate and the one by networkaudiod on BBB was either 28-38% with no error or 85% with xrun error.

Can you provide corresponding output from networkaudiod for the same? The period size should scale with sampling rate unless the driver is restricting the possible period size range.

 

[twluke]

...


Can you provide corresponding output from networkaudiod for the same? The period size should scale with sampling rate unless the driver is restricting the possible period size range.

Sorry to say that I'm not sure what you mean. I think the output from networkaudiod on BBB/Botic is already shown on the last post. If you mean the result of top command, it looks like below:

top - 09:07:28 up 39 min,  2 users,  load average: 2.66, 2.20, 1.79
Tasks:  95 total,   1 running,  94 sleeping,   0 stopped,   0 zombie
%Cpu(s): 19.2 us, 17.1 sy,  0.0 ni, 53.0 id,  0.0 wa,  0.0 hi, 10.7 si,  0.0 st
KiB Mem :   509672 total,   413512 free,    36072 used,    60088 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   456636 avail Mem 

without xrun error

  476 root      10 -10   21044   9760   2668 R 37.5  1.9   9:33.80 networkaudi+
    3 root      20   0       0      0      0 R  3.3  0.0   0:36.19 ksoftirqd/0 
  786 root      20   0    6832   2744   2288 R  1.6  0.5   0:19.96 top         

with xrun error

  476 root      10 -10   21268   9764   2668 S 59.7  1.9  10:45.42 networkaudi+
  150 root      20   0   21372   2904   2604 S  3.5  0.6   0:19.97 systemd-jou+
    3 root      20   0       0      0      0 S  2.6  0.0   0:41.18 ksoftirqd/0

As for [FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica]/proc/asound/card0/pcm0p/sub0/[/FONT][/FONT][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica]hw_params, I noticed [/FONT][/FONT][/FONT][/FONT][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica]that, while [/FONT][/FONT][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica][FONT=Verdana,Arial,Helvetica]the selection of sample rates on HPQ setting panel is well reflected, [/FONT][/FONT]the period_size and buffer_size still remained fixed even on playing PCM sources as shown below.

access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 8192
buffer_size: 16384
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 88200 (88200/1)
period_size: 8192
buffer_size: 16384
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 176400 (176400/1)
period_size: 8192
buffer_size: 16384
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 352800 (352800/1)
period_size: 8192
buffer_size: 16384

Shown below are more detailed log messages of Botic NAA during the initiation of DSD512 session on HQP including the occurrence of xrun recovery issue. It appears that networkaudiod is trying to determine the period size to a fixed value.

Jul  3 07:58:32 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): Found ALSA device: hw:0,0 - Botic:
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): begin disconnection
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA backend uninitialized
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): disconnected [::ffff:192.168.0.55]:60636
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): connection from [::ffff:192.168.0.55]:60637
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA backend uninitialized
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): Set channels: 2 (2)
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA device: hw:0,0
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA access mode: 3
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format: S32_LE
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM bits: 32
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM physical width: 32
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM rates: 11025 - 768000
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format: DSD_U32_LE
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD bits: 32
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD physical width: 32
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD rates: 352800 - 24576000
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 32000
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 44100
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 48000
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 64000
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 88200
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 96000
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 128000
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 176400
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 192000
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 256000
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 352800
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 384000
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 512000
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 705600
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 768000
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA backend initialized
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 32000/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 44100/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 48000/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 64000/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 88200/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 96000/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 128000/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 176400/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 192000/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 256000/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 352800/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 384000/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 512000/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 705600/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA PCM format available: 768000/32/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format available: 2048000/1/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format available: 2822400/1/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format available: 3072000/1/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format available: 4096000/1/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format available: 5644800/1/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format available: 6144000/1/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format available: 8192000/1/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format available: 11289600/1/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format available: 12288000/1/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format available: 16384000/1/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format available: 22579200/1/2
Jul  3 07:58:33 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA DSD format available: 24576000/1/2
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): start 22579200/1/2 [dsd]
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 2048000
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 2822400
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 3072000
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 4096000
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 5644800
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 6144000
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 8192000
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 11289600
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 12288000
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 16384000
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 22579200
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA rate available: 24576000
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): Set channels: 2 (2)
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): Set sampling rate: 22579200 (22579200)
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA engine starting...
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA channels: 2 - 8
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA active channels: 2
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA number of periods: 2
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA period times: 5 - 11610
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA period sizes: 4 - 8192
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA period time: 11609
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA period size: 8192
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA engine started at: 22579200 (22579200)
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): enter streaming mode
Jul  3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA engine running...
Jul  3 07:59:19 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA attempting X-run recovery...
Jul  3 07:59:21 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA attempting X-run recovery...
Jul  3 07:59:26 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA attempting X-run recovery...
Jul  3 07:59:26 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA attempting X-run recovery...

[/FONT][/FONT]

 

[nautibuoy]

So it's my impression that the issue may be associated with the current build of networkaudiod and the BBB/Botic will be basically work as a solid NAA.
The situation may change in a future version of networkaudiod.

Thanks for your work on this 'tw'.

I've not had much time to work on this over the last week and you seem to have superior knowledge of Linux than I so your efforts are really helping to push this forward.

I did spend a little time just taking stock of where I am with this yesterday and concluded that, configured as a BBB/Botic/NAA consistent playback of DSD512 (and 384KHz PCM) is very close. BTW, I was seeing similar feedback via 'top' to that you reported.

I am convinced that the peak loading on the BBB is an affect not a cause (of the dropouts/machine gun noise) and the xrun error you've identified would seem to confirm that. Likewise, the performance monitoring on the Win10 HQP PC is simply reacting to the BBB issue.

Hopefully Jussi will be able understand what is happening.

 

[Signalyst]

Jul 3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA period times: 5 - 11610
Jul 3 07:58:58 arm networkaudiod[543]: [/usr/sbin/networkaudiod] (543): ALSA period sizes: 4 - 8192

You see, here is the problem... By default networkaudiod would like to use 100 ms period size which would be 70560 for DSD512. However, driver is limited to sizes of 4 - 8192 so networkaudiod has to stick to the largest size supported by the driver which when translated to time is 12 ms at DSD512... Which you can also see on the above line - "ALSA period times: 5 - 11610" - values are in microseconds.

 

[twluke]

You see, here is the problem... By default networkaudiod would like to use 100 ms period size which would be 70560 for DSD512. However, driver is limited to sizes of 4 - 8192 so networkaudiod has to stick to the largest size supported by the driver which when translated to time is 12 ms at DSD512... Which you can also see on the above line - "ALSA period times: 5 - 11610" - values are in microseconds.

Hi Miska,

Thank you for your quick reply and I really appreciated your clear explanation on this issue. I thought the value of period size might be the culprit of this ring buffer error but wrongly assumed that the NAA daemon is responsible to it. Sorry for my misunderstanding.

Well, the solution of this issue appears to require the revision of Botic driver by the author.

Regards,

 

[nautibuoy]

You see, here is the problem... By default networkaudiod would like to use 100 ms period size which would be 70560 for DSD512. However, driver is limited to sizes of 4 - 8192 so networkaudiod has to stick to the largest size supported by the driver which when translated to time is 12 ms at DSD512... Which you can also see on the above line - "ALSA period times: 5 - 11610" - values are in microseconds.

Thanks for the analysis Jussi, hopefully miero will be able to help.

 

[miero]

OK, you can try this patch for botic7-rc1 that allocates larger buffers:

cd /lib/modules/4.5.0-botic7-rc1/kernel/sound/soc/davinci
# backup original module
mv snd-soc-edma.ko snd-soc-edma.ko.orig
# download module with larger buffers
wget http://bbb.ieero.com/botic7-rc1/snd-soc-edma.ko
# restart
sync
reboot
# try it ...

BTW: If you are using USB Wifi dongle, you might want to change it to Ethernet - it is faster - no xruns with small buffers.

 

[nautibuoy]

OK, you can try this patch for botic7-rc1 that allocates larger buffers:


BTW: If you are using USB Wifi dongle, you might want to change it to Ethernet - it is faster - no xruns with small buffers.

Thank you miero, I will try to find the time to test it this evening. I'm only using Ethernet.