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)
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).
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:
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.
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.
Yes, this was intended as a quick fix for x86, but as it seems the x86-specific version will be replacing it after all.
This version of “Install To Disk” is taking a slightly different approach. It does not do a full clone, but a “factory” copy of the boot device it is being copied from. But instead, super fast (less than 50 secs).
The update worked properly from 3.049 to 3.051.
So now I’m testing on version 2021-03-06-x86_amd64-volumiobuster-3.051
I had to deactivate / activate myVolumio for my device to see TIDAL again. Normally it is there after an update without this step. Volumio radio selection is there (some of them are not working, perhaps someone should check all the entries…? )
I’ll give the “install to disk” a try later on.
Also a freshly flashed stick will be testet later (initial bosst problem to be investigated…).
