@balbuze: see above my and @Hermann 's first post in this thread.
When flashing the beta image you have to boot twice because some tasks seem to hang and there’s no playback, no local library scan,…
After the first boot you have to wait a few minutes, then restart the system and after that it works fine.
This is kind of a weird behaviour - looks like a race condition at startup or some processes have dependencies that are not propperly defined.
I can reproduce this problem reliably here.
Hi @Robert.Hecht That was only on the initial boot - strangely. Every subsequent boot was fine, so no longer have the issue. It actually boots up much faster now than before - now using 3.049. I’m wondering if @gkkpch has been able to make any progress on bytcr-es8316 audio device?
Hi @Hermann,
same here. Only the first boot after fresh flashing the stick is bad.
I can reproduce exactly this:
- Flash the image,
- boot
- problem
- reboot
- everything works.
Now i tested this on my Minix Z64. It works perfectly fine.
Initially i boot from USB to evaluate. Then i wrote the image to disk becasue it was running smooth. Now it boots of the internal disk and all the updates also works fine to disk.
The wifi also works fine. But i switched back to LAN as i prefer it.
My Arcam is detected on the USB and the playback is working fine.
The HDMI is detected with a strange name. But i don’t use it for now.
The file scan on NAS also worked fine and the library is updated perfectly.
@gkkpch : Thank you for the excellent work. Waiting for the release with plugins enabled. For now will install the few manually.
Could you tell me anyway?
aplay -l
will do.
Here is the result
volumio@volumio:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: bytcrrt5640 [bytcr-rt5640], device 0: Baytrail Audio () []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: bytcrrt5640 [bytcr-rt5640], device 1: Deep-Buffer Audio ()
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: A20 [ARCAM USB Audio 2.0], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Audio [Intel HDMI/DP LPE Audio], device 0: HdmiLpeAudio [Intel HDMI/DP LPE Audi]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Audio [Intel HDMI/DP LPE Audio], device 1: HdmiLpeAudio [Intel HDMI/DP LPE Audi]
Subdevices: 1/1
Subdevice #0: subdevice #0
volumio@volumio:~$
Great, a second baytrail based device someone can help test with.
I have a bytcr-rt5460 here as well, we should be able to get your headphone out working with it.
Perhaps it already does, seems this rt5640 codec needs to have resampling set to 16bit.
Would be interesting if you could send me the URL of a logfile (after a fresh restart to keep it short enough 
RT5640 is sort of working here, next version will have something more to test with.
New version may also have improvement for the bycht-es8316 (@Hermann)
1 Like
What should I do with my two netbooks with Atom x86 32bits processors running volumio x86 buster debian? I was waiting according to what was indicated by gkkpch for the incorporation of plug-ins, specifically Spotify … and now I have to throw everything in the trash and buy new hardware? … and even so I must wait for the appearance of the plug-ins …? It is true? … it seems like a joke!
Mar 05 11:01:18 volumio kernel: bytcr_rt5640 bytcr_rt5640: quirk realtek,jack-detect-source 2
Mar 05 11:01:18 volumio kernel: bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-threshold-microamp 2000
Mar 05 11:01:18 volumio kernel: bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-scale-factor 1
Mar 05 11:01:18 volumio kernel: bytcr_rt5640 bytcr_rt5640: quirk DIFF_MIC enabled
Mar 05 11:01:18 volumio kernel: bytcr_rt5640 bytcr_rt5640: quirk SSP0_AIF2 enabled
Mar 05 11:01:18 volumio kernel: bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled
Mar 05 11:01:18 volumio kernel: input: bytcr-rt5640 Headset as /devices/platform/80860F28:00/bytcr_rt5640/sound/card0/input4
Seems to initialise OK, but I do not find the sound card tweak script kicking in just before/after “startx”.
This is probably because it only runs once, after a fresh install.
To check, see folder “/usr/share/alsa/ucm/bytch-rt5640”, when it has a file called “firsttime.done” your headphones should actually work.
As mentioned, you may have to activate resampling to use 16bit, we will be not be able to automate this as that would require kernel code changes, which I try to avoid.
Also, the hw mixer has to be changed to DAC1 manually, this will be added to a next version.
Would you please read what we wrote about the Beta phase, start with the announcement (you will find it here) and the rules that apply in case you like to participate.
If you don’t like what you see, then please don’t bother, we have better things to do than answering stupid complaints in a thread that is not meant for that.
*".If you don’t like what you see, then please don’t bother, we have better things to do than answering stupid complaints in a thread that is not meant for that."
gkkpch said…Dec 2020:
"shairport issue fixed
samba issue fixed
plugins issue fixed
version for x86_i386 (32bit) upcoming
version for x86_amd64 (64bit) upcoming
we will be testing with kernel 4.19.164 and 5.10.4 to see which one suites us best to start."
feb 18 ,2021…
…"Not too bad, just not quite finished.
Don’t worry, they will come soon."
thanks for your sincerity, I am many things but not stupid
Would you please carry this discussion somewhere else and not pollute this thread?
Read the announcement and the rules. It says what we have and what we expect from you if you participate.
What we currently have is x86 64bit, if that is not what you want, then this beta phase is not for you, simple as that.
Yes, the problem lies here, we set up the Intel HDMI/DP LPE Audio device with HDMI on device 2, which you do not seem to have. Not sure yet how to handle this. Perhaps we need to call it HDMI 0, HDMI 1 (and HDMI 2 in our case) and let the enduser decide which one to use.
At boot time, for your audio card, spdif will always be unmuted.
Would be interesting to know spdif is then already routed as output, independent of what you selected as output channel?
In other words, would spdif always be active after that?
We do not explicitly mute or unmute spdif, we may have to do some more testing to find out what exactly happens here.
had a look today, this does not appear to be as easy as it looks, I don’t see any prompt for VIRTIO_NET without having to disable a number of other settings.
Not willing to do that at this stage as I do not know what impact that has on our further testing.
But, in case you want to help, send me a working kernel config to compare. Perhaps I can get you an offline version when you can make it interesting enough ( = not risking other settings).
Hi gkkpch,
I did some investigations about that. Meanwhile 3.049 is running here.
There are three output options in my setup: analog out, HDMI, SPDIF
Once the device is running (1st boot, reboot, you know. ):
select SPDIF: HDMI and analog out are quiet 
select HDMI: SPDIF and analog out are quiet
select analog out: HDMI is quiet, SPDIF is active. 
It doesn’t matter in what sequence you do the above, the result is always the same.
So it looks like SPDIF is muted (or deactivated in another way) when selecting HDMI as output but it es not muted (deactivated) when selecting analog out.
When you reboot in between:
select HDMI -> reboot -> HDMI is selectet and active, SPDIF and analog out are muted.
select analog out -> reboot -> analog out is selectet and active, SPDIF is active , HDMI is muted.
select SPDIF -> reboot -> SPDIF is selectet and active, analog out and HDMI are muted.
There is obviously no “muting” as you can see in the alsamixer:
selected analog out:
selected HDMI:
selected SPDIF
Can I provide you with some more information?
Cheers,
Robert
Understood and of course no problem, I just wanted to give beta-feedback, as 2.86 had virtio-support for NIC at least.
Aside from the usecase: Everything seems to run fine, the ancient Onkyo-Soundcard works well in this beta up to 96/24. Strange enough, neither in 2.86 nor in this beta I was able to upsample to 192/24 which the card should support. But this ist clearly no relevant usecase, so don’t bother.
OK, i should be able to reproduce that exact behavior on one of the devices here.
Thanks!
Ah, that is very interesting, thanks for pointing that out!
There was a configuration change I did a few weeks ago, other than that it was taken from the earlier beta series.