search

ralph-irving / squeezelite

Lightweight headless squeezebox player for Lyrion Media Server
https://sourceforge.net/projects/lmsclients/files/squeezelite/
Other
386 stars 98 forks source link

Possible issue with Topping E30 DAC #114

Closed slartibartfast3 closed 3 years ago

slartibartfast3 commented 3 years ago

When I connect via USB from piCorePlayer 7.0.0b6 beta to a Topping E30 DAC I have an issue when the DAC comes out of standby. The DAC display shows 45.15 DSD before changing to the correct sample rate accompanied by an audible pop. This video demonstrates the issue https://youtu.be/1-cQD3mnxzw. The Touch is synced to the pCP for a now playing display. The only reason I think it might be an issue with Squeezelite is because when I use the Squeezebox Touch with EDO to feed the DAC the issue doesn't occur.

ralph-irving commented 3 years ago

I'm not sure how this can be an issue with one specific usb DAC but here are some things to test. If you remove sync between the touch and pcp do you still see the problem? What if you enable the -C 5 option, does it still happen? Have you tried setting the delay parameter in your -D setting?

slartibartfast3 commented 3 years ago

Yes the issue occurs whether synced or not With -C 5 and delay of 1000ms, when the DAC comes out of standby the display shows 45.15 DSD until I start playing a track at which point the display changes to 44.1 PCM and the same audible noise occurs just before the track starts to play

clivem commented 3 years ago

AK449x DAC chip is not known for being click/pop free, when powering-on, starting playback, changing sample rate or switching between DSD and PCM modes. ISTR a lot of discussion about pops/clicks from the Topping E30 on the www.audiosciencereview.com/forum

slartibartfast3 commented 3 years ago

I haven't noticed pops when sample rates change in normal use or when switching from DSD to PCM. If they exist they must be very low level. This is much louder. The mystery is why is 45.15 DSD displayed at all when the DAC comes out of standby. It doesn't happen with the Touch.

clivem commented 3 years ago

Touch EDO driver is old. It probably doesn't even have support for DSD. Can you even play native DSD via Touch EDO? Are you actually playing DSD? Or just when you start playing PCM audio via squeezelite, the DAC displays "45.15 DSD" and then when it actually starts playing, shows something different. eg. PCM 44k1? If the DAC is detecting DSD (for whatever reason) and then switching to PCM, (unless the designer has done something to mitigate it), it will pop/click. And I suspect at the price point that model sells for, (as good as it may be), it won't have a relay on the output to shunt to ground, whilst changing mode from DSD to PCM, or sample rate, which is what you will usually find on a DAC using the AK49xx series chips at higher price points. The fact that the AK DAC chips are not noise free when switching mode is not a secret. Still doesn't help get to the bottom of this. Sorry.

slartibartfast3 commented 3 years ago

I am not playing DSD when this issue occurs but the DAC displays DSD when coming out of standby with piCorePlayer feeding it. I have tried playing DSD on other occasions and haven't noticed any noises when changing to PCM. This only happens when coming out of standby. It just seems odd that the DAC displays 45.15 DSD. Others using Roon and Moode have reported the same thing. I can work around it by avoiding standby. Alternatively my amplifier has a speaker delay relay which rides throught the DAC start up time.

clivem commented 3 years ago

I'm confused. You are not talking about squeezelite being in "standby". ie not playing? The actual DAC has a standby mode, low power state - display off, or you are physically switching it into a standby mode. Then when you bring the DAC out of standby mode, power it back up, it shows the 45.15 DSD. Then that 45.15 DSD doesn't change until you start streaming music again with squeezelite, (which is in standby), at which point the DAC switches mode? So the DAC starts up in 45.15 DSD with squeezelite not actually playing anything?

slartibartfast3 commented 3 years ago

Squeezelite is not playing but is powered on and connected to the DAC. DAC is in standby. When DAC comes out of standby 45.15 DSD shows on the display for a couple of seconds before changing to the last known sample rate.

ralph-irving commented 3 years ago

That's likely because 44.1KHz is the initial sample rate squeezelite uses to open the device at start, then if the stream uses a different rate the audio device is closed and reopened at the required speed. Squeezelite has no idea what the sample rate of the stream will be initially, but needs to use some sample rate to open the device and as 44.1 is still the most common, that's the default.

slartibartfast3 commented 3 years ago

I did some more investigating. I run a script to control the pCP USB port turning the port on when the player is powered on and off when the player is powered off. I modified this to turn on the port for 1s to bring the DAC out of standby followed by a 15s delay before the port is turned on again.

squeezelite sets $1 to:

0: off

1: on

----------------------------------------------------------------------------------------

case $1 in 0) uhubctl -l 1-1 -p 4 -a 0 >/dev/null 2>&1 ;; 1) uhubctl -l 1-1 -p 4 -a 1 sleep 1s uhubctl -l 1-1 -p 4 -a 0 sleep 15s uhubctl -l 1-1 -p 4 -a 1 >/dev/null 2>&1 ;; esac

In this case the noise occurs at the moment that the USB port turns on after the 15 second delay. This is accompanied by the 45,15 DSD followed by 44.1 a couple of seconds later. So the noise isn't associated with the "sample rate" change. If I then turn the player off so the USB port also turns off the display shows that the player is disconnected but if I turn the player on again (before the DAC enters standby) then there is no noise when the USB port turns on again. So the noise occurs when the USB port is turned on but only if the DAC has been in standby. This seems different to the case when the DAC comes out of standby when the USB port is on.

clivem commented 3 years ago

How is the DAC powered? Is it powered by the USB port or does it have a standalone power supply?

slartibartfast3 commented 3 years ago

Standalone power supply.

clivem commented 3 years ago

Rather than continue to speculate, someone I know who owns an E30 has just agreed to loan it to me. Should have it to test sometime next week.

slartibartfast3 commented 3 years ago

Excellent news.

clivem commented 3 years ago

@ralph-irving Do you still package squeezelite for piCorePlayer and have contact with those guys? Can you get the following udev rule added to piCorePlayer for the chap with this Topping E30 DAC?

01-Topping-E30-DAC-usb-power.rules ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="152a", ATTR{idProduct}=="8750", TEST=="power/control", ATTR{power/control}="auto"

Working within the confines of squeezelite behaviour, and the behaviour of the E30 DACs decision making process of whether to go into standby, (it detects lack of 5V on USB port rather than zero samples), this is the best solution. The behaviour with this rule is that user "powers" squeezelite from web gui or starts playing music, USB DAC is woken with a sample rate and the clock started on the XMOS side of things, which prevents the scenario where DAC comes out of standby by default in DSD512 mode displaying 45.15.... Likewise "power down" squeezelite player, squeezelite releases audio interface, linux USB layer kills power to USB port, 20 secs later DAC enter standby and stays there until, squeezelite is resumed, at which point linux USB layer powers the port again. No nasty noises, as the situation is prevented where the DAC ends up in the default config of DSD512.

ralph-irving commented 3 years ago

Yes, I do still package SL for pcp, I'll talk to Paul tomorrow, if he doesn't notice this before that. Thanks for researching this Clive.

slartibartfast3 commented 3 years ago

@ralph-irving Do you still package squeezelite for piCorePlayer and have contact with those guys? Can you get the following udev rule added to piCorePlayer for the chap with this Topping E30 DAC?

01-Topping-E30-DAC-usb-power.rules ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="152a", ATTR{idProduct}=="8750", TEST=="power/control", ATTR{power/control}="auto"

Working within the confines of squeezelite behaviour, and the behaviour of the E30 DACs decision making process of whether to go into standby, (it detects lack of 5V on USB port rather than zero samples), this is the best solution. The behaviour with this rule is that user "powers" squeezelite from web gui or starts playing music, USB DAC is woken with a sample rate and the clock started on the XMOS side of things, which prevents the scenario where DAC comes out of standby by default in DSD512 mode displaying 45.15.... Likewise "power down" squeezelite player, squeezelite releases audio interface, linux USB layer kills power to USB port, 20 secs later DAC enter standby and stays there until, squeezelite is resumed, at which point linux USB layer powers the port again. No nasty noises, as the situation is prevented where the DAC ends up in the default config of DSD512.

Is there a way I can try this out? I tried copying a file into the udev rules folder in WinSCP but permission was denied.

clivem commented 3 years ago

@slartibartfast3 Yes, piCorePlayer uses a read-only fs, which is why I asked @ralph-irving if he could get it added to the next build of their OS image. Your procedure until then is to use the E30 remote to put DAC into standby, AFTER you power-off squeezelite from LMS web gui. DAC should remain in standby, until you power squeezelite back on from the web gui, which should cause DAC to come out of standby without the glitch. (Make sure you have removed the '-C' option from any squeezelite config. You want squeezelite to open and keep open the audio interface, if it is powered on, regardless of whether anything is playing or not.)

slartibartfast3 commented 3 years ago

My turn to be confused. Are you saying that putting the DAC into standby using the remote after powering off Squeezelite is different to allowing the DAC to enter standby automatically one minute after powering off squeezelite?

slartibartfast3 commented 3 years ago

I tried the sequence you suggested and still hear the glitch.

slartibartfast3 commented 3 years ago

The only way I have found to avoid the glitch is to reboot piCorePlayer.

clivem commented 3 years ago

This is starting to look like a rabbit hole that I'm going to wish I never went down. LOL I've emailed the manufacturer, because after a conversation with two other owners, (the guy who loaned me the DAC, (which he says is the latest model - he also owns an earlier production model from the first batch which apparently behaves differently with regard to glitches/pops/clicks), I'm not willing to get any deeper into this without knowing how many "revisions" of this product there actually are out there and how the revisions differ. There appears to be at least 3 different revisions on firmware for the XMOS USB chip, 2 for the MCU, and at least one hardware revision of the board. Whatever changes they made to the MCU firmware can only be "upgraded" by sending the unit back to China - which apparently is why my friend just bought another which was supposed to have bugs fixed.... One of the hardware changes is to do with glitches/pops/clicks - I think they added output coupling caps to get rid of DC offset on the output when changing mode from PCM to DSD or sample rate change. And of course none of this revision appears to be documented. If I had a penny for every time I came across this sort of stuff with these Chi-Fi products.... And it's such a shame, because they've actually made a decent sounding DAC. What's that old saying? [sarcasm]You get what you pay for![/sarcasm]

ralph-irving commented 3 years ago

As a test I've created a separate pcp extension with the udev rule. You'll need to ssh into your picoreplayer and execute the following commands.

ceo

wget http://ralph-irving.users.sourceforge.net/pico/usb-power.tcz

wget http://ralph-irving.users.sourceforge.net/pico/usb-power.tcz.md5.txt

md5sum -c usb-power.tcz.md5.txt 

tce-load -i usb-power

echo usb-power.tcz >> ../onboot.lst

pcp br

Your picoreplayer will backup the current configuation and reboot.

After the reboot you should have the new udev rule.

cat /lib/udev/rules.d/01-topping-e30-dac-usb-power.rules

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="152a", ATTR{idProduct}=="8750", TEST=="power/control", ATTR{power/control}="auto"
slartibartfast3 commented 3 years ago

I don't think the design has been changed since serial numbers beginning 2004.

Braklet commented 3 years ago

You guys are making me very, very happy that I found a halfway decent Chi-Fi i2s DAC.  Love that "Chi-Fi" term, by the way.

On Wednesday, November 25, 2020, 09:25:44 AM EST, Clive Messer notifications@github.com wrote:

And of course none of this revision appears to be documented. If I had a penny for every time I came across this sort of stuff with these Chi-Fi products.... And it's such a shame, because they've actually made a decent sounding DAC. What's that old saying? [sarcasm]You get what you pay for![/sarcasm]

slartibartfast3 commented 3 years ago

As a test I've created a separate pcp extension with the udev rule. You'll need to ssh into your picoreplayer and execute the following commands.

ceo

wget http://ralph-irving.users.sourceforge.net/pico/usb-power.tcz

wget http://ralph-irving.users.sourceforge.net/pico/usb-power.tcz.md5.txt

md5sum -c usb-power.tcz.md5.txt 

tce-load -i usb-power

echo usb-power.tcz >> ../onboot.lst

pcp br

Your picoreplayer will backup the current configuation and reboot.

After the reboot you should have the new udev rule.

cat /lib/udev/rules.d/01-topping-e30-dac-usb-power.rules

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="152a", ATTR{idProduct}=="8750", TEST=="power/control", ATTR{power/control}="auto"

Sorry to say no noticeable difference for me.

clivem commented 3 years ago

With that rule, the behaviour I see is.... Play music. Power off squeezelite instance from LMS web-gui - within 1 second, display on the E30 changes from the displayed sample rate to "---" and USB symbol flashes. 1 minute later, E30 display turns off, only leaving the "." at the bottom lit, indicating it is in standby. After it is in standby, power on squeezelite from weg-gui. If you have nothing in the playlist, DAC displays 44.1k or the sample rate of the track, which has started auto-playing in my setup. What you should not see is the change from 45.15 DSD to a something else and the sound of the glitch that accompanies it.

slartibartfast3 commented 3 years ago

With that rule, the behaviour I see is.... Play music. Power off squeezelite instance from LMS web-gui - within 1 second, display on the E30 changes from the displayed sample rate to "---" and USB symbol flashes. 1 minute later, E30 display turns off, only leaving the "." at the bottom lit, indicating it is in standby. After it is in standby, power on squeezelite from weg-gui. If you have nothing in the playlist, DAC displays 44.1k or the sample rate of the track, which has started auto-playing in my setup. What you should not see is the change from 45.15 DSD to a something else and the sound of the glitch that accompanies it.

Do I still need a script to turn off the USB port on pCP? Without the script then the DAC never goes into standby.

clivem commented 3 years ago

No, do not use your script that was brute force turning off power to port.

clivem commented 3 years ago

You do have auto-standby enabled on the DAC, right?

slartibartfast3 commented 3 years ago

No, do not use your script that was brute force turning off power to port.

without the script the DAC does not go into standby when I turn off squeezelite using the power toggle in Material skin which must be the same as from the webUI

clivem commented 3 years ago

That rule is sufficient to get the DAC to go into standby if I have auto-standby enabled on the DAC. (Which it should be unless you changed it. AUTO button on remote.)

slartibartfast3 commented 3 years ago

That rule is sufficient to get the DAC to go into standby if I have auto-standby enabled on the DAC. (Which it should be unless you changed it. AUTO button on remote.)

Does it matter that the rule is not in the etc/udev/rules.d folder?

clivem commented 3 years ago

Shouldn't matter whether in the /lib... or /etc... path, but I'm not an expert of the Linux distribution that PCP is built on.

slartibartfast3 commented 3 years ago

Shouldn't matter whether in the /lib... or /etc... path, but I'm not an expert of the Linux distribution that PCP is built on.

It is in the folder Ralph specified but nothing happens when I toggle the power on squeezelite.

slartibartfast3 commented 3 years ago

You do have auto-standby enabled on the DAC, right?

Absolutely it was going into standby with my script turning off the USB power.

slartibartfast3 commented 3 years ago

How can I tell the rule is being used?

clivem commented 3 years ago

2 possibilities.... 1) differences between revision DAC you have and mine. 2) udev rule not being executed. Which I'd normally degug on a "full fledged" Linux distribution by enabling udev debug, unplug/replug DAC and check for power being set to auto. But whether the udevadm command exists on TinyCore, I don't know. sudo udevadm control --log-priority=debug PLUG/UNPLUG DAC journalctl -b | grep topping | grep auto returns Nov 25 16:05:12 Akkordion3B1 systemd-udevd[6641]: 1-1.5: ATTR '/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/power/control' writing 'auto' /etc/udev/rules.d/01-topping-e30-dac-usb-power-auto.rules:1

But to be honest, it's probably best to stop here. Until my questions to Topping are answered, I'm concerned that the behaviour of E30 DAC's isn't consistent from unit to unit, depending on XMOS firmware, MCU firmware and board revision.

slartibartfast3 commented 3 years ago

What are the first 4 numbers in your serial number, mine is 2009

clivem commented 3 years ago

Sorry, have to let you know later. I'm just on my way out to a meeting.

slartibartfast3 commented 3 years ago

I a

2 possibilities.... 1) differences between revision DAC you have and mine. 2) udev rule not being executed. Which I'd normally degug on a "full fledged" Linux distribution by enabling udev debug, unplug/replug DAC and check for power being set to auto. But whether the udevadm command exists on TinyCore, I don't know. sudo udevadm control --log-priority=debug PLUG/UNPLUG DAC journalctl -b | grep topping | grep auto returns Nov 25 16:05:12 Akkordion3B1 systemd-udevd[6641]: 1-1.5: ATTR '/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/power/control' writing 'auto' /etc/udev/rules.d/01-topping-e30-dac-usb-power-auto.rules:1

But to be honest, it's probably best to stop here. Until my questions to Topping are answered, I'm concerned that the behaviour of E30 DAC's isn't consistent from unit to unit, depending on XMOS firmware, MCU firmware and board revision.

I added your rules file to a squeezelite instance installed on Raspbian Buster and it works perfectly so something has gone wrong with my pCP version.

Braklet commented 3 years ago

udevadm is implemented in piCorePlayer, mine is running v6.1.0:

tc@piCorePorch:~$ sudo udevadm control --help Usage: udevadm control COMMAND   --exit                   instruct the daemon to cleanup and exit   --log-priority=   set the udev log level for the daemon   --stop-exec-queue        keep udevd from executing events, queue only   --start-exec-queue       execute events, flush queue   --reload-rules           reloads the rules files   --property== set a global property for all events   --children-max=       maximum number of children   --timeout=      maximum time to block for a reply   --help                   print this help text

On Wednesday, November 25, 2020, 01:17:47 PM EST, slartibartfast3 notifications@github.com wrote:

I a

   2 possibilities.... 1) differences between revision DAC you have and mine. 2) udev rule not being executed. Which I'd normally degug on a "full fledged" Linux distribution by enabling udev debug, unplug/replug DAC and check for power being set to auto. But whether the udevadm command exists on TinyCore, I don't know. sudo udevadm control --log-priority=debug PLUG/UNPLUG DAC journalctl -b | grep topping | grep auto returns Nov 25 16:05:12 Akkordion3B1 systemd-udevd[6641]: 1-1.5: ATTR '/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/power/control' writing 'auto' /etc/udev/rules.d/01-topping-e30-dac-usb-power-auto.rules:1

But to be honest, it's probably best to stop here. Until my questions to Topping are answered, I'm concerned that the behaviour of E30 DAC's isn't consistent from unit to unit, depending on XMOS firmware, MCU firmware and board revision.

I added your rules file to a squeezelite instance installed on Raspbian Buster and it works perfectly so something has gone wrong with my pCP version.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe .

slartibartfast3 commented 3 years ago

Somehow I have usb-power,tcz appearing twice in my onboot.lst. How do I remove one of them?

pcp.tcz pcp-7.0.0b6-www.tcz firmware-atheros.tcz firmware-brcmwifi.tcz firmware-ralinkwifi.tcz firmware-rtlwifi.tcz firmware-rpi-wifi.tcz wireless_tools.tcz wpa_supplicant.tcz uhubctl.tcz bash.tcz usb-power.tcz usb-power.tcz

ralph-irving commented 3 years ago

Edit the file with vi and delete one of them. If you're not comfortable using vi then install the nano extension and use that to edit onboot.lst

slartibartfast3 commented 3 years ago

I uninstalled usb-power.tcz then went through the installation instructions again and now I only have one instance. I still cannot get the rule to work on pCP though. I have another squeezelite instance on a Pi4 running Raspbian Buster and it works perfectly.

slartibartfast3 commented 3 years ago

udevadm is implemented in piCorePlayer, mine is running v6.1.0: tc@piCorePorch:~$ sudo udevadm control --help Usage: udevadm control COMMAND --exit instruct the daemon to cleanup and exit --log-priority= set the udev log level for the daemon --stop-exec-queue keep udevd from executing events, queue only --start-exec-queue execute events, flush queue --reload-rules reloads the rules files --property== set a global property for all events --children-max= maximum number of children --timeout= maximum time to block for a reply --help print this help text On Wednesday, November 25, 2020, 01:17:47 PM EST, slartibartfast3 notifications@github.com wrote: I a 2 possibilities.... 1) differences between revision DAC you have and mine. 2) udev rule not being executed. Which I'd normally degug on a "full fledged" Linux distribution by enabling udev debug, unplug/replug DAC and check for power being set to auto. But whether the udevadm command exists on TinyCore, I don't know. sudo udevadm control --log-priority=debug PLUG/UNPLUG DAC journalctl -b | grep topping | grep auto returns Nov 25 16:05:12 Akkordion3B1 systemd-udevd[6641]: 1-1.5: ATTR '/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/power/control' writing 'auto' /etc/udev/rules.d/01-topping-e30-dac-usb-power-auto.rules:1 But to be honest, it's probably best to stop here. Until my questions to Topping are answered, I'm concerned that the behaviour of E30 DAC's isn't consistent from unit to unit, depending on XMOS firmware, MCU firmware and board revision. I added your rules file to a squeezelite instance installed on Raspbian Buster and it works perfectly so something has gone wrong with my pCP version. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe .

That command seemed to run OK but journalctl doesn't run for me.

Braklet commented 3 years ago

journalctl is just the systemd-compliant log management utility.  PCP has other means to access the system logs, suggest you try dmesg instead.  Something like:

dmesg | grep topping | grep auto

I haven't futzed around with udev in years but on my PCP system this coughs up a bunch of USB device related events:

dmesg | grep usb

On Wednesday, November 25, 2020, 02:44:57 PM EST, slartibartfast3 notifications@github.com wrote:

[udevadm] command seemed to run OK but journalctl doesn't run for me.

slartibartfast3 commented 3 years ago

dmesg | grep Topping | grep auto produces no output so it looks like the rule is not running.

clivem commented 3 years ago

@slartibartfast3 Sorry to say I'm really snowed-under with work at the moment. I'll take another look at this at the weekend, installing PCP myself and try to understand why that udev rule isn't working with PCP. In any event, at least we know that it is possible to make your DAC auto-standby using it on Raspbian. Hopefully by that time the manufacturer will have answered my technical questions as well. @ralph-irving In the interests of full disclosure, I didn't want to mention this until I had confirmed this myself, but again wont be able to until the weekend. Bottom line, you/Paul/Steen might want to hold-off adding this to PCP. It seems that putting that DAC into auto-standby prevents a Pi from rebooting from USB - it doesn't come back up. Which to be fair, probably doesn't matter for PCP where I suspect 100% of users are booting from SDCARD. Symptoms are that if the DAC is in standby when the system reboots, Pi's bootloader isn't able to identify any other connected USB device (flash drive, SSD attached via USB)..... sounds like the DAC in standby is hanging the bus, but as I say, I wont be able to investigate myself before the weekend.

slartibartfast3 commented 3 years ago

No rush @clivem work comes first. Thanks for taking the time to investigate.