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.
