On 27/08/2023 23:53, Gregory Nutt wrote:
On 8/27/2023 4:22 PM, Tim Hardisty wrote:
The classD driver DOES register itself as /dev/audio/pcm0, and works
correctly as such with nx_player.
You are mistaken. The Class D driver does not register itself as a
character driver. grep -r register_driver arch/arm/src/sama5/ proves
that is true.
The logic that registers /dev/audio/pcm0 is in audio/audio.c.
audio/Kconfig defines the directory. Nothing is the code base except
files in audio/ knows about that directory or is capable of registering
a driver there.
config AUDIO_DEV_PATH
string "Base path for Audio devices"
default "/dev/audio"
audio/audio.c:
audio/audio.c: FAR const char *devname = CONFIG_AUDIO_DEV_PATH;
Most certainly the class D lower half cannot be register as a driver.
That is totally impossible. It is not a character driver; it is only
the lower half of a driver. It contains no usable driver logic; only
the low level hardware interface.
You must be using audio_register() in your board start up logic. That is
part of the configuration of the audio chain. It does NOT produce a PCM
driver. The driver is the audio chain that starts in audio/audio.c.
Class D is the terminus of the audio chain and cannot be accessed using
/dev/audio/pcm0. It has that name only because that is the name that
you gave it when you called audio_register. The entire audio chain
supports PCM, but the driver is the audio.c driver.
he conversions are wav (or mp3 etc) to pcm.
Don’t if we’re talking cross purposes or the classd driver works in a
way it shouldn’t!!!
In the previous email I listed the only place in the code base where a
driver is registered at /dev/audio/pcm0 for any SAMA5 board. The only
cases in the code base do PCM to WAV conversion. That is done by
audio/pcm_decode.c. You may have some other audio logic that uses the
Class D to handle PCM directly, I don't know. If so, it is not in the
source tree. Certainly that driver is not sam_classd.c.
sam_classd.c is not a driver in the POSIX sense. It is only a hardware
lower half. It could never possibly be registered as a driver. It
doesn't support the standard driver calls. In the terminology of the
audio subsystem, it is called an audio driver. It is the sink at the end
of the audio chain managed by the logic in audio/.
I am indeed mistaken. Guilty as charged! I tend to think in
"generalisations" and "know" that the lower half ClassD "driver" allows
for /dev/audio/pcm0 to be registered just did't (bother to) think about
the exact details of it. I apologise.
So:
1) A basic character write to /dev/audio/pcm0 is not supported by any
existing lower half driver so it is not good for me to add this to
ClassD for any reason.
2) The upper-half driver only deals with audio buffers, sent to the
lower half driver via buffer enqueuing.
3) So I either add a function to my code to create sinewaves on the fly
and write to a buffer and send these to /dev/audio/pcm0 correctly; or I
extend/modify/make-use-of/base-new-code-on existing NuttX apps to do the
same.
Have I got it now? I don't want to use romfs .wav files as that is not
flexible enough (as I can't predict all the tones I *might* want).
