-
-
Notifications
You must be signed in to change notification settings - Fork 501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sparky SBC | Kernel error trace when switching audio source on USB DAC #2610
Comments
@seniorgod Will investigate, need to have a look into the sound card selection code. As you use MPD, please first apply this fix that causes permission issues that might or might not be related to your issue: #2522 (comment) Okay so you selected The config is done quite straight forward with that. I don't believe something can fail here. Will check the software installs... Software installs as well do no special sound configs. Could you paste output of:
|
|
To do new set up with the sparky the Friday, i started with an image i downloaded last December. I think it was Dietpi 6.14. I called dietpi-config to update all to the new version. The language of the system is german. sorry. :-)
mpd is working fine |
one question regarding #2522 |
No advantage as long as you add them correctly to the right line.
The reason why this caused issues was:
If MPD already works fine for you, you possible already changed something about that (e.g. setting Okay so you use a quite generic USB DAC and at least to ALSA it is exactly configured as desired. About the fix within the Linux kernel, this was actually only a certain USB WiFi dongle: https://www.viatech.com/en/support/eol/vnt6656-usb-module-dongle-eol/ Identified the code line that produces the error, which is about USB low level messaging: https://github.com/sparkysbc/Linux/blob/master/drivers/usb/core/urb.c#L328
I am trying to find out what this is all about. I guess the source is indeed:
Do the timestamps of this error match track switch? Looks like since first log is
But as every thing runs well, I guess for now these errors can be ignored. However where do they show up actually, journalctl? Perhaps it is possible to reduce some log level to not have them spamming 😉. |
thank you, most things are clear. |
@seniorgod
Mostly we use this internally within DietPi scripts, but it is available from the command line by default on DietPi systems. And nope, reinstall will currently still place the default |
understand. fine. :-) What we do with the kernel problem? |
@seniorgod Ah can you verify these errors (timestamps) show up when switching the audio source and/or track and not randomly in the middle of playing any source? The first error messages come from |
hm,
i loaded spotifyd because spotify-connect-web don’t work for me. (and i have no idea why)
spotifyd seems to be newer, and as far as i understand it is a new implementation with rust, with uses the new spotify web api.
But i never get a own compile to work. Something in rust was outdated and i get now answer from the spotifyd group.
As far as i understand the future of the „old“ spotify lib and app keys, there will come the day when we all have to move from the old spotifylib world to a new one……
Do you plan to move from spotify-connect-web to spotifyd in future?
… Am 03.03.2019 um 18:46 schrieb MichaIng ***@***.***>:
@seniorgod <https://github.com/seniorgod>
Not sure about the kernel issue currently, if it is indeed related to the audio source transition and thus software related or a kernel bug indeed.
Ah can you verify these errors (timestamps) show up when switching the audio source and/or track and not randomly in the middle of playing any source?
The first error messages come from spotifyd, so I assume, if software related, then it is more likely a spotifyd issue then sharepoint-sync.
Also our shairport-sync packages are already the most current upstream version. But indeed there are several build options, where I am not 100% sure if anything might be related: https://github.com/mikebrady/shairport-sync#building-and-installing <https://github.com/mikebrady/shairport-sync#building-and-installing>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#2610 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQWpjpvYnOL_0L5tjjBN8_4cmWnSv_Axks5vTApegaJpZM4bariO>.
|
@seniorgod Would be great if you could open a new feature request about this and possible as well add it to our FeatHub page: https://feathub.com/MichaIng/DietPi/ |
@seniorgod In Reboot and check if it makes a difference. |
nice try:-) #2427 was created by me. To remember: the behavior if atop_urb_fix != 0 is that sparky hang, after shutting of the DAC while music is playing. what i wonder: I give a new compilation of shairport-sync a try. But i have to wait for next week, will go skiing at weekend..... |
@seniorgod User programs generally can trigger kernel error when using kernel features a wrong way, accessing resources they have no permissions for or in case of general I/O issues due to corruption and stuff. But yeah to be true I am not sure how exactly the audio device is accessed here. Of course ALSA is always middleware and also always shows up in your error log, but possible it is accessed/used wrong by the players... But as well possible that it is indeed a kernel issue Sparky-side: Actually would be great to test the exact same setup on another SBC. Hmm actually I have an USB DAC here as well, perhaps I find some time to test it on notebook. Hmm have no spotify or something, have to digging a bid into this to have two sources to switch between. The setup will be totally different, but at least we can sort out a general issue with Debian + ALSA + switch audio source. But I mark this as low priority now, since functionality is fine and it is a visual issue only. |
Hi MichaIng, i have a new error trace. But today only spotifyd was running. No other music client was playing music (but all run as daemons):
spotifyd is a precompiled version..... |
@seniorgod I cannot say reliably if it is newer or older than the one from our image, since ours has overwritten timestamps from image creation date. There is no documentation about it so I have no idea what this uImage does differently than the default one, but according to the name it has something to do with USB DACs. So if you find some time you could:
|
All sparky kernel updates are patched during our updates. Allo provides these to me directly. Therefor once DietPi is updated, users are running the latest kernel, as provided by Allo. |
Yeah I tried that too. Just goes back to “none “. |
@M1m1s
Is there another chance to test the USBridge general functionality with something else than a DAC? I guess this port is only for audio output, isn't it? Otherwise one could check if some USB flash or such get's powered at least, if you own one with LED.
😞 However always worth to still give it a try and contact Allo regardless. Perhaps they will still help 🙂. |
@MichaIng Thanks for chiming in, in addition to @Fourdee! These lines from dmesg may be relevant:
Also:
Other red lines:
No mention of USB in journalctl. Thank you! |
@M1m1s
It might not exactly apply in your case, but with some luck some recent change in the USB audio driver magically fixes the issue. At least worth to give the new testing drivers a try: #2610 (comment) Also:
EDIT:
|
@MichaIng @Fourdee Thank you so much for your very helpful and extensive troubleshooting help for the USBridge (over the weekend, too!). I have performed all your suggestions, as well as verified that the DAC and USB cable work properly. I'm in contact with Allo support. All your help is very appreciated and hopefully will help anyone else who might experience similar issues. |
Dear all, sorry for late reply, but i was absent and afterwards "under heavy workload". @MichaIng: Thank you for noticing the new driver. I installed it last week.
|
@seniorgod @MichaIng @Fourdee |
@M1m1s |
@seniorgod
|
I mark this as closed as of new Sparky SBC image and new Shairport-Sync build. Feel free to reopen if required. |
Creating a bug report/issue
Required Information
i still test my allo sparky with USBridge after upgrading to 6.21.1
I have several audio software installed
shairport-sync from dietpi installation
spotifyd from GitHub (because i never get shairport-sync to work properly)
mpd with upmpdcli as upnp frontend for mpd
i control my music with my mobile phone, running spotify, apple music, mpdeluxe.
spotiyfyd and shairport-sny use plughw:1,0 as audio device. When i hear a song from apple music and start playing music from spotify, the system smoothly change the music from one source and go to the second music source (e.g. from apple music to spotify). It seems, that "plughw" stop the first stream and start the new stream.
But i get, from time to time, the following error.
Is it an error resulting from spotifyd/shairport-sync or is it problem of the driver?
The text was updated successfully, but these errors were encountered: