Sort of perhaps. The SAMA5D@ needs lots of setting up and the existing driver does that with all the usual audio device ioctls and enqueue methods: it works just fine using nxplayer and can playback .wav files etc.
But it it is based on creating buffers of audio - the assumption being that you are playing back long(ish) streams of audio, so the buffer/queue methods make sense. To play a brief tone it just seems like a lot of hassle to generate a 0.5s (say) buffer of sinewave pcm date when it is really only necessary to write it sample by sample to the (already configured) ClassD device at /dev/audio/pcm0 and have the driver manage the buffer and ready flags etc. I will add other notes in an answer to Gregory's reply to this. On 27/08/2023 05:59, Tomek CEDRO wrote: On Sat, Aug 26, 2023, 20:18 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 :) you mean /dev/dsp ? https://man.freebsd.org/cgi/man.cgi?query=sound&apropos=0&manpath=FreeBSD+13.2-RELEASE+and+Ports -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
