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.
