OK, new problem. USB extrernal drive connected directly to the pi by cable. When formatted ext4, it shows up in the list of USB mounts, but no files are read into the library. When the same drive is reformatted exFAT, there are files visible.
Any ideas?
Any ideas?
The USB interface is a lower layer than the file system.... are you mounting the drive correctly?
https://gordonlesti.com/mount-ext4-usb-flash-drive-to-raspberry-pi/
https://gordonlesti.com/mount-ext4-usb-flash-drive-to-raspberry-pi/
Prolly permissions. I have several systems with ext4 USB and NVMe disks and no issues whatsoever.
https://mpd.readthedocs.io/en/stable/user.html#database
OK! Thank you Tim!
Permissions started as:
drwx------ 5 jeremy jeremy 4096 Jun 6 21:58 ext4thumb
chown & chmod got me to:
drwxr-xr-x 5 root root 4096 Jun 6 21:58 ext4thumb
Then guess what happened?
Yup. New library entries.
How can I make this automatic/persistent? Say I take my 4TB drive which I had formatted as exFAT while troubleshooting and reformat it ext4 - will I need to do this terminal surgery every reboot or will the permission and owner change stick?
Does the owner need to be root root? Or will 755 permissions on jeremy jeremy be enough?
I know almost enough to be dangerous, go slow....
Permissions started as:
drwx------ 5 jeremy jeremy 4096 Jun 6 21:58 ext4thumb
chown & chmod got me to:
drwxr-xr-x 5 root root 4096 Jun 6 21:58 ext4thumb
Then guess what happened?
Yup. New library entries.
How can I make this automatic/persistent? Say I take my 4TB drive which I had formatted as exFAT while troubleshooting and reformat it ext4 - will I need to do this terminal surgery every reboot or will the permission and owner change stick?
Does the owner need to be root root? Or will 755 permissions on jeremy jeremy be enough?
I know almost enough to be dangerous, go slow....
Then your configuration is incorrect.
The link I sent you has more links.
Not only must the USB connection be made - to enable the data link- but the transport layer must also be configured. When you mount the drive you can specify the filesystem type... you would need some means of automatically identify the filesystem type when the USB device is identified and connected.
In the short term, just use exFAT formatting and/or try manually mounting the drive. See if you can get that working first.... then you will need to see how to make so it will self mount when you plug it in via USB.
I created a Raspberry 5 last year, with the defaults, and I have no trouble mounting and seeing ext4 filesystems when I plug in a USB stick.
The link I sent you has more links.
Not only must the USB connection be made - to enable the data link- but the transport layer must also be configured. When you mount the drive you can specify the filesystem type... you would need some means of automatically identify the filesystem type when the USB device is identified and connected.
In the short term, just use exFAT formatting and/or try manually mounting the drive. See if you can get that working first.... then you will need to see how to make so it will self mount when you plug it in via USB.
I created a Raspberry 5 last year, with the defaults, and I have no trouble mounting and seeing ext4 filesystems when I plug in a USB stick.
You're not wrong and after providing irrefutable evidence of the inner workings of a ARM processor and the mechanisms of direct memory transfers and the architecture of the linux audio subsystem these clueless audiophiles ignore reality and believe that the processor is somehow randomly modifying the Moode audio buffer data in such a way that it results in audio ecstasy is beyond audiophoolery nonsense.
LOOK, it's not what I feel, it's not theoretical principles, it is how it works internally. It's called analysis based on Computer Engineering Architecture.
It's not what I think, it's what we were measuring (in this case measurements make sense) when we ran the AXI, AHB and even the PCI bus.... I spend years with my nose stuck on the debuggers and the development tools.
If Nelson Pass tells you something about an analog amp you listen to him because that's his experience. If he says the issue is not in his amp, you believe him, right?
If you bought a cell phone ( Android or Apple ) in the late teens with a BCM SoC then you were hardware designed with some of my device drivers. Of course, I was only one of a hundred of R&D engineers and, unlike Nelson, my work is covered by NDAs to the hilt. Pretty much my colleagues over at Qualcomm, Apple, Nokia, Samsung, etc... were all doing the same thing!
We used Palladium emulators to verify the RTL design, with really fancy debuggers and a Lauterbach JTAG debugger as well. When we taped the design and got the silicon back, we used more ARM debugging tools and the JTAG debugger.
Spent months.. heck years, specially as I actually wrote the code and the stress tests for the DMA, which meant I was using all kinds of peripherals that fed the modem, the network and the multimedia modules... yep... that meant the digital audio interfaces such as I2s (someone else in my team wrote that driver, but we were running all kinds of stress tests on the design... worst case test cases, with the smallest buffers you can imagine... which were forcing the streamer software to make lots, LOTS of frequent requests for data..). Heck our job was to stress the device to find out its limits and corner cases... and we NEVER saw a buffer size cause any kind of drop outs or change in the sound quality of the DAC renderer. Never saw any jitter at the DAC (which was our own RTL IP in the SoC).
We were running this in our SoCs, and our Raspberries (2s and 3s then). Using bare metal, ThreadX and Android (kernel).
The ONLY way you could ever see a buffer issue is if someone had written really, REALLY bad streamer code that run in a loop, main thread, in the kernel. Something that would break the deterministic behavior of the cores. Something that a High End audio company might do because they're CHEAP when it comes of the firmware, which is very expensive to develop... specially for low volume products.
However, I have not seen anyone write such crappy streamer software in an Open Source distro as they would be laughed out from the Open Source project to begin with.
If you drain an buffer in a transmission chain, you will end up with drop out... audio, video, data, cell voice... etc.
+++
OK, forget the jitter... what could be happening?
So.... when you are changing the size of buffers... take a look in more detail at what buffers you are really changing... There could be internal streaming buffer that if they run down, they force the really badly designed streamer software to repeat the same sample... it could be... that would be terribly bad software design.... And, combined with this, you could have a really, truly bad streaming source with really narrow and/or bursty bandwidth... so that if your buffers are too small, you are draining them and your bad software is repeating some samples so as to not stop the DAC from stopping the sound...
A corner case of bad design with insufficient network capacity that ignores Quality Of Service.
But these things have nothing to do with the jitter... none at all.
+++
What kind of a source are you using for your audio? A 28K modem? 802.11b with several devices? Your problem is NOT jitter in the I2S or anywhere within the Raspberry. It could be upfront.
Try a different datalink for your streamer. Try a robust, high bandwidth source... say a USB stick reading a file. See if the data buffers make any difference. Do not run any other application software when you do this.
..
BTW, have you ever played with something like Tidal? If you are running on streaming from the network, if you lose the connection, it stops the music. If you had a huge buffer at the network front end, it might allow you to handle the network timeouts.... but this has NOTHING to do with jitter.
...
That's pretty much it...
Last edited: