开云体育

Has anyone considered not use the Linux sound drivers for the WM8731 codec, but instead reading / writing the dat directly to / from the codec directly using I2S?
--
73,
Mark, N8ME

Yeap, that would be possible. I wrote about this some months ago. The WM8731 alsa driver itself is a good source of information.

Rafael PU2UIT

Yes, I plan on looking at the driver source. Do you know if the driver uses DMA? I know with the Raspberry Pi Pico, DMA can be used to reduce the load on the main processor and improve timing.
--
73,
Mark, N8ME

This is the kind of feedback I am looking for. Thanks.

My thinking was that the WM8731 is only used by the sBitx software, so it doesn’t need to be part of the OS.

FWIW, I think the battery backed RTC should be setting the system clock, so it’s time would be available to all programs, and I have modified my RPi configuration accordingly.

I am assuming that if you had a user space driver for the WM 8731, you could load the standard BCM audio driver in config.txt (dtparam=audio=on) and use other audio outputs on the RPi, for example the AV or HDMI jacks for stereo output (for dual receive or output from other programs). It also might allow the code to properly initialize the codec. I have seen times where the receiver appears dead or receives multiple copies of the same signals that are not where the radio is tuned, and a reboot or power cycle fixes it. I am assuming that the linux driver did not properly reset the codec.

Speaking of that, is there a way to reset the codec in those situations other than a reboot or power cycle?
--
73,
Mark, N8ME

Thanks for the tip on trying aplay when it acts up.
--
73,
Mark, N8ME

Hi all,

This is the kind of feedback I am looking for. Thanks.

My thinking was that the WM8731 is only used by the sBitx software, so it doesn’t need to be part of the OS.

You would lose the ability to easily "genlock" (tru hwtimer aloop module parameter) the alsa loopback to the actual wm8731 alsa device. I tried a bit to get rid of alsa, and it would be a not small work.

FWIW, I think the battery backed RTC should be setting the system clock, so it’s time would be available to all programs, and I have modified my RPi configuration accordingly.

I am assuming that if you had a user space driver for the WM 8731, you could load the standard BCM audio driver in config.txt (dtparam=audio=on) and use other audio outputs on the RPi, for example the AV or HDMI jacks for stereo output (for dual receive or output from other programs). It also might allow the code to properly initialize the codec. I have seen times where the receiver appears dead or receives multiple copies of the same signals that are not where the radio is tuned, and a reboot or power cycle fixes it. I am assuming that the linux driver did not properly reset the codec.

I don't see any reason why you can not use other ALSA devices. You can - just make sure the order they are brought up so not to confuse userland.

- Rafael

Btw, I've seem some wm8731 lock-ups indeed. We should properly solve the issue or add a workaround to the driver itself, instead of bringing everything to userland (which indeed would not solve the problem... just make a "stop and start again" procedure easier).

Anyway, if you really want to get rid of ALSA, lemme know, I also want, I just did not have the time to understand which interfaces to keep kernel side and how to interact to userland.

- Rafael

On Mon, Sep 4, 2023 at 06:23 AM, Rafael Diniz wrote:

I don't see any reason why you can not use other ALSA devices. You can - just make sure the order they are brought up so not to confuse userland.

Again, sorry if I'm digging up an old thread, but the topic popped up again.

I think the right approach is not to rely on order of bring up, the answer is to use more specific names.

Use?"plughw:CARD=audioinjectorpi,DEV=0" instead of?"hw:0,0" and you'll always get the Wolfson codec and not someone's HDMI speakers or USB headset.

I wrote about this in??




This is another area where a quick PR could put this to bed quickly.

My problem is like yours, in that my code base has diverged from the afarhan sbitx github repo so much that it's hard to do PRs now.

But maybe I'll find the time to do a PR anyhow, we shall see.

Then we'll see how long it takes for that PR to be merged.

?
--
Regards,
Dave, N1AI