Raspberry Pi4 announced

cdsgames · 2019-07-25 10:49 am

Here you go.

Test data of Usbridge/audiophile SBC vs RPI4/Usb3 using our Revolution Dac

You can see the pattern change . (Blue is Usbridge , Red RPI4)

PS. All PSUs are same (Shanti feeding with one output USB source and another output feeding USB Dac)

cdsgames · 2019-07-25 11:32 am

* Are u running USB DAC tests? Which DAC?

Revolution dac our new design, using Xmos

* How does the I2S situation Pi3/4 look like? With isolators, reclockers, separate power rails in place?

We briefly looked at i2s , seems similar to RPI3B+

* It's not really clear to me - reading your post - what the differences are between own USB transport, RPI3B+, RPI3 ?

RPI 3B and RPI4B show small differences in harmonics pattern on USB

* Setup? WLAN, wired, local playback, local data, streaming..

Wired. We wanted to test the most stable connection .

phofman · 2019-07-25 12:32 pm

cdsgames: Please can you make the measurements of your USB-based DAC at non-multiple of 1kHz, e.g. 1211Hz? Many USB soundcards/DACs have a 1Khz artefact and measuring at 1kHz fundamental hides that. Thanks.

soundcheck · 2019-07-25 1:00 pm

@cdsgames

Your measurements nicely show that

1. a standard computer is causing more trouble than a customized USB audio
transport, BUT it also shows that

2. the audio interface is not (yet?) able to properly cope with different
transports

We discussed it before. In a perfect world with a perfect DAC both of your measurements should look the same.
Meaning.
A well done DAC should be able to cope with whatever transport it gets attached to as long as 0=0 and 1=1.
Obviously that's not the case. I'd really prefer to see the DAC performing
equally on whatever transport it gets attached to.
It's 2019. And I'm having these kind of discussions since 2007/2008. It's getting better after all. But we're still not there yet.

However. Since most of the USB DACs out there probably show a similar non-perfect behavior
as the one you outlined, I'd say it's still a great business opportunity to
design and market a HQ USB transport.

Good luck with that.

cdsgames · 2019-07-25 1:26 pm

phofman said:
cdsgames: Please can you make the measurements of your USB-based DAC at non-multiple of 1kHz, e.g. 1211Hz? Many USB soundcards/DACs have a 1Khz artefact and measuring at 1kHz fundamental hides that. Thanks.

I am unable to test with 1211Hz since I used a file playing on the media . (that is hi quality)

Do you have such test file ? I will gladly measure it

I think that 1Khz or 1211Hz testing , my point is that you can clearly see the harmonic change depending on USB source .

Yes 0 and 1, but in isochronous mode( USB) there is no error checking or retransmission's. We will try to see if any errors at Xmos input. (thats my theory )

On USbridge/Audiohile SBC , great care was taken on the transmission path (USB hub is very close to USB output ,traces were optimized) so I think that not only noise on USB line but transmission integrity is very, very important.

That might be the explanation also for why USB cables make a diff in audio quality.. (not all USB cables are correctly made in terms of impedance and connector resistance)

matthiasw · 2019-07-25 1:48 pm

soundcheck said:
A well done DAC should be able to cope with whatever transport it gets attached to as long as 0=0 and 1=1.
Obviously that's not the case. I'd really prefer to see the DAC performing
equally on whatever transport it gets attached to.
It's 2019. And I'm having these kind of discussions since 2007/2008. It's getting better after all. But we're still not there yet.

You will never get it.
The source or transport determines the quality for the DAC.
The DAC converts what is offered to it.
It is the same as in pure analogue systems.

Matt

phofman · 2019-07-25 2:20 pm

cdsgames said:
I am unable to test with 1211Hz since I used a file playing on the media . (that is hi quality)

Do you have such test file ? I will gladly measure it

It's trivial to generate any file you want with SoX - Sound eXchange | HomePage

24bit, 2channel, 192kHz, flac, 60 secs, 1211Hz, -1dB max, stored to file 1211Hz.flac

Code:

 sox -V -r 192000 -n -b 24 -c 2 -r 192000 1211Hz.flac synth 60 sine 1211 gain -1
sox:      SoX v14.4.1

Input File     : '' (null)
Channels       : 1
Sample Rate    : 192000
Precision      : 32-bit

sox INFO sox: Overwriting `1211Hz.flac'
sox INFO flac: encoding at 24 bits per sample
sox INFO flac: non-standard rate; output may not be streamable

Output File    : '1211Hz.flac'
Channels       : 2
Sample Rate    : 192000
Precision      : 24-bit
Sample Encoding: 24-bit FLAC
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no
Comment        : 'Processed by SoX'

sox INFO sox: effects chain: input       192000Hz  1 channels
sox INFO sox: effects chain: synth       192000Hz  1 channels
sox INFO sox: effects chain: gain        192000Hz  1 channels
sox INFO sox: effects chain: channels    192000Hz  2 channels
sox INFO sox: effects chain: output      192000Hz  2 channels

Check - e.g. command soxi, part of the sox package:

Code:

soxi 1211Hz.flac 

Input File     : '1211Hz.flac'
Channels       : 2
Sample Rate    : 192000
Precision      : 24-bit
Duration       : 00:01:00.00 = 11520000 samples ~ 4500 CDDA sectors
File Size      : 8.69M
Bit Rate       : 1.16M
Sample Encoding: 24-bit FLAC
Comment        : 'Comment=Processed by SoX'

I think that 1Khz or 1211Hz testing , my point is that you can clearly see the harmonic change depending on USB source .

Is it harmonic distortion of your DAC, or noise signal coming from the USB host, or noise on the PSU? By choosing a different frequency than 1kHz you have a chance to tell more.

Actually the harmonics envelopment looks like slight limitation of the DAC output. PSU limit? Your signal seems to hit the 0dB ceiling. What happens if you lower the input e.g. to -1dB (as generated by the sox command above)?

Yes 0 and 1, but in isochronous mode( USB) there is no error checking or retransmission's. We will try to see if any errors at Xmos input. (thats my theory )

These are not digital transmission errors, in no way could a digital error consistently add a row of higher harmonics at -130dBFS. It is either the DAC output slightly limiting, or some 1kHz + multiples noise coming from somewhere else (USB, PSU). Again, use a different frequency to tell.

On USbridge/Audiohile SBC , great care was taken on the transmission path (USB hub is very close to USB output ,traces were optimized) so I think that not only noise on USB line but transmission integrity is very, very important

.

You are a USB hardware developer, I would assume you know how your USB works. Data payload in USB frames is accompanied with CRC checksums USB (Communications) - Wikipedia . Does your USB receiver (XMOS) drop the frame payload when it detects a checksum error (it should according to USB specs)? What does it substitute for the lost 1ms (or 125us for USB2) of data? But whatever it does, it will definitely not result in the minor 1kHz x N peaks we see on the spectrum, a loss of even 125us of data is audible, not something at -130dB.

That might be the explanation also for why USB cables make a diff in audio quality.. (not all USB cables are correctly made in terms of impedance and connector resistance)

USB cables may transfer the HF noise differently. But they are not introducing transmission errors creating harmonics at -130dB.

androa76 · 2019-07-25 2:41 pm

Discussion about sound (also partly mesurements) related to Rpi should be explained more precisse. ...what power supply, what software, what cable, what usb bridge-card (suplied independet or trought rpi), what dac...
Combination that i use is till now unbeatable from any rpi i2s bridge configuration. Only interested candidate for me is Ian stack. But too expenssive to just try.
For music streaming no need for rpi 4..5... in direction of processor speed, wifi, bluetooth. Sometimess is less bether.

cdsgames · 2019-07-25 3:09 pm

Hi Phoman

I will check the SOX.

PSU is the same , so we can remove that from equation . With the same setup , only change is the USB source (RPI vs ours). Change in harmonics are related only to source

Its not possible to have output limiting since its the same file playing on the same analog stage .

I dont specialize in USB , but I have never seen a 1Khz noise on USB hi speed lines (I have seen 8Khz )

phofman · 2019-07-25 3:30 pm

I have never seen a 1Khz noise on USB hi speed lines (I have seen 8Khz )

Did you check it is really running on highspeed (480MHz)? Even USB2 can run on fullspeed (12MHz), using 1ms frames (1kHz). Actually I would not be surprised if the USB speeds were different for RPi4 USB3 hub vs. your USB hub chip. I do not know how your XMOS firmware signals the required speed to the USB controller/hub. You can find out easily with lsusb -t on any linux (RPI):

Code:

hestia@hestia:~$ lsusb -t
/:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
    |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
    |__ Port 6: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 4: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 4: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M

My E-MU 0404USB, while USB2 device, has minor 1kHz artefacts too https://www.diyaudio.com/forums/equ...nsation-measurement-setup-24.html#post5832094 . The fact is I did not check if high or full speed and I have it disassembled now.

But using a non-1Khz signal will show right away if it is a USB artefact or harmonic distortion. Still it will not tell the source of the USB artefact (XMOS can produce it for full speed, entirely possible).

cdsgames · 2019-07-25 4:13 pm

We are measuring a 24/192Khz file that can only be used with USB hi speed

Anyway I will check with a file thats slightly different

phofman · 2019-07-25 4:45 pm

Hm, why a different file? Actually I would keep the same file and try to diagnose the cause. There must be a reason for the different spectrum.

I assume you have checked the file is being played by a bit-perfect chain (no dither, no resampling, no attenuation) in both cases.

phofman · 2019-07-25 4:50 pm

Sorry, not the same file, but the same a non-1kHz file in both scenarios.

cdsgames · 2019-07-25 6:06 pm

this is not our first test on RPI using AP. We took probably thousands of of them.

The conclusion (even on 1Khz file) is clear. RPI4 changes the harmonics.

phofman · 2019-07-25 7:25 pm

Well, all I can say is the two spectra presented are different. There is no additional information provided to make such conclusion for me. It could just as easily be a lower-quality resampling (pulseaudio in the way), or resampling too close to 0dB with minor clipping (two LSBs), or simply higher level of digital signal, making the DAC start limiting, or anything else. But whatever, I will not buy either.

cdsgames · 2019-07-26 9:17 am

Dimdim said:
I finally got around to doing a proper (albeit somewhat rushed) A-B test between the RPi 3 and RPi 4 as audio streamers.

To keep the playing field as level as possible both of them were running the exact same software (Raspbian Buster Lite) with MPD loaded and were powered by the same (excellent) Salas L-Adapter PS.

Connection to my DAC (DIY dual AK4493, very detailed) was through USB.

The music streamed from a NAS box over Ethernet.

I had a friend over in order to at least try to have a bigger sample size (of ears).

The music used was a handful of tracks that we always use for such comparisons (well known material).

We listened using the RPi3, then shut it down and booted up the RPi4, listening to the same material.

Much to our surprise, we actually preferred the sound of the RPi3!

The RPi4's presentation had something of a "fatiguing" effect. The sound was a bit more "coarse" that that of the RPi3.

We are not talking about big differences here, but they were there.

So it seems like I'll be going ahead with my "Audio Pi" project after all (I was considering waiting for the Compute Module 4 to come out).

I'm really curious if anyone else has done such a comparison and come to a similar conclusion.

Dimdim , I have done extensive testing and will publish more in the upcoming weeks.

sq225917 · 2019-07-26 9:53 am

There's some awfully large logic jumps being made in these comparisons that one could drive a bus through. It's bad science.

cdsgames · 2019-07-26 11:26 am

Are you referring to the AP test data ?

LinuxGeek · 2019-07-26 3:12 pm

I told it in a wrong way :
USB implementation on the RPI is crippled from a software developer point of view. The drivers are cruel. They do not fully support USB 2.0 implementation and to be honest, i do not know why they run... This USB implementation suffers from many many problems. Of course, if you run it async, it is not really important, because the DAC itself manages the data fetching over a DMA transfer (although im not sure its DMA in the RPI

).
Dont undrestand me wrong, it runs yes, but its simply a mess...

soundcheck · 2019-10-17 8:02 am

PI4 UPDATE.

Meanwhile I bought a RPI4.

However. The dust still has everything but settled. The typical 2-3 month period is all but applicable for the PI4. Too much has changed.

So far I'm more then happy though.

As a headless audio streamer it just works fine. I already prefer it over
my PI3B+.

I'm currently running ALARM with a 64bit rt-kernel and (still)
a 32bit userland feeding this or that HAT DAC.
On my 3B+ I'm meanwhile running 64bit kernel and 64bit userland btw.

I'd recommend to have a look at the new "rpi-eeprom" firmware update toolbox.
It's IMO worthwhile to install the latest firmware.
There's AFAIK no automatic update process in place yet - for sure not on my Arch Linux installation.
And my just recently delivered PI4 still had the initial firmware onboard!

The flawed USB power port is still an issue on the Pi4. No update yet as it seems.

Several of the tweaks I'm able to apply on my Pi3, such as turning USB off altogether, are still not working.
The USB-off feature alone saved me 200mA (40%@800MHz) on the PI3.

HDMI-off is not working either.

The whole new PCIe-USB infrastructure seems to be work-in-progress.
Therefore you should have a closer look at this:

The new USB controller from VLI runs it's own firmware.
There's a tool to run the firmware updates. Afaik there's also no automated update-process in place.

Installing the latest VLI firmware brought my current-draw down by 100mA to 480mA idle @ 800MHz. That's really nice.
E.g. The Shanti 1A output can still be used - at least under these conditions.

Beside that, temperature also got down a little (5-10%) with all the new FW installed. I'm measuring 48C at 800MHz without cooling. This way I can run the device easily without cooling.

All in all I'm more then happy with the situation. The PI4 IMO is a great device.

As usual there's still some work to do. That keeps us going.

Enjoy.

Raspberry Pi4 announced

Member

Attachments

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member