[riot-notifications] [RIOT-OS/RIOT] drivers/periph_common: dac: add dac_play() (#13908)

chrysn notifications at github.com
Mon Nov 9 09:05:54 CET 2020


>From my initial look over this:

* (How) Can the application detect that it ran into an underflow? (I'm not sure it needs to, yet, but from an "errors should never occur silently" point of view, it'd seem like a good idea.)
* AFAIR @bergzand had experiments around for USB sound cards (but I don't find any PR). Comparing what was done there might help see whether the proposed API is practical.
* DMA operation will probably be specific to the chips and need more than just a generic DMA peripheral -- but we can still go there in time. (As can hooking them up to external DACs, probably via I2S).
* If dac_dds_set_cb is allowed to be called while playing (as "on the fly" implies), it'll need atomics or a critical section around writing that. I'm not sure how relevant that function is in practice, though -- outside of demos, how often do you change the data source without at the same time allowing to change the data format (sample rate and bit depth), in which case you're right back at dac_dds_init.
    * If a full format switch is called for (as would be the case when enabling gapless playback, even though where most needed, gapless is between like-formatted data anyway), can the API (or can it be extended to -- I'd be happy with a rough roadmap) do that in a double-buffered fashion? (I think so, it'd just need to double-buffer bit format as well and call timer_set_periodic without RESET_ON_SET when switching buffers, but maybe it'd be more complicated.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/13908#issuecomment-723840486
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20201109/6bd0c007/attachment.htm>


More information about the notifications mailing list