Looking a little more at the write function of audio_ops_s it is not used by any existing driver and is documented to be for device-specific information...so it is not portable in terms of playing tones by simply writing PCM data word by word. I get that now.
So I'm thinking the right way is possibly either: 1) Complete the "tone" support of nxplayer - it exists as a command parameter but has no underlying code/functions 2) create a tone player as a standalone (example) app that opens /dev/audio/pcm%d and makes use of the audio_ops_s functions and ioctls to set up a NuttX sound system compliant device and play tones. That is then portable and can be used with any supported audio device without having to use nxplayer in its entirety. e.g you could run, from nsh something like: "pcmtone <device> <samp_rate> <freq> <millesecs>" so "pcm_tone /dev/pcm0 48 1000 500" to play a 1kHz tone using 48 sampling for 500ms. Looks like there are similar functions "out there" I could reference. Is that more along the right lines perhaps? On 27/08/2023 11:17, Tim Hardisty wrote: Thanks Gregory. The existing ClassD driver is registered as /dev/audio/pcm0 and is a PCM device not PWM. It has the "usual" audio ops to configure it, start/stop/pause/enqueue etc. It is exposed via ioctls so does have a user interface; that is how buffers of audio are passed to it. Is that an OS-function only, hence your comments that it should not be exposed to the user and I'm muddling things up? The declaration of the audio_ops_s struct also includes a read and write function that are typically defined as NULL in these audio drivers. That's what I was thinking of adding, but perhaps I'm am not understanding that /dev/audio/pcm0 can't (shouldn't) actually be opened as a character driver? Sorry for the dumb questions! On 26/08/2023 23:10, Gregory Nutt wrote: On 8/26/2023 12:18 PM, Tim Hardisty wrote: This is, I'm sure, more a generic POSIX question than NuttX-specific but I am still not that familiar with either! When I wrote the SAMA5D2 ClassD audio driver I followed the methods appropriate for using "apb" so it works well with nxplayer (for example). But I want to play simple audio tones, from a sine look-up table, and filling a buffer and enqueuing it seems over the top. Is there any reason - from a "correctness" point of view - I couldn't add a basic file write function to the driver that allows you to simply fwrite to the opened device and have it dump data that way? A simple piece of code that simply writes to the processor audio sample buffer, word at a time, and polls the "ready" bit works 100% fine but this is not portable! So if such an interface is not "right" I won't add it :) I don't think it makes sense to add a write method to the audio driver interface. That is not driver is not POSIX and cannot be exposed as a user interface. I suggest thinking about this in a different way. How about an audio source driver that exposes two interfaces: (1) The audio interface that is (ONLY) used inside of the OS and certain audio applications (which it really shouldn't). An audio driver can be a source of audio data, a sink of audio data, or can intercept and modify audio data in the audio chain. And (2) a standard character driver that accepts audio input from application space. The character driver is POSIX and does support the write method. So any data written via the character driver interface would be treated as audio source data.
