experimental change support async audio and other enhancements #1
Conversation
| @@ -175,7 +175,7 @@ endif | |||
| # Remove -Wno-stringop-overflow after we can test with CI's GCC 10. Mac's looks weird. | |||
| DISABLE_WARNINGS = -Wno-stringop-overflow -Wno-cast-align | |||
|
|
|||
| CFLAGS += $(INC) -Wall -Werror -std=gnu11 -nostdlib -fshort-enums $(BASE_CFLAGS) $(CFLAGS_MOD) $(COPT) $(DISABLE_WARNINGS) -Werror=missing-prototypes | |||
| CFLAGS += $(INC) -Wall -Werror -std=gnu11 -fshort-enums $(BASE_CFLAGS) $(CFLAGS_MOD) $(COPT) $(DISABLE_WARNINGS) -Werror=missing-prototypes | |||
There was a problem hiding this comment.
Could you explain why you are now using stdlib?
| uint8_t ch = (uint8_t)uart_get_hw(uart)->dr; | ||
| if (ch == mp_interrupt_char) { | ||
| mp_sched_keyboard_interrupt(); | ||
| continue; | ||
| } | ||
| ringbuf_put(r, ch); |
There was a problem hiding this comment.
I don't understand why you are checking for ctrl-C in raw UART reading.
There was a problem hiding this comment.
Every port is meant to do this, but it was missing from this port. This is how ctrl-C is implemented. I discovered this because I was using the uart instead of usb cdc and ctrl-c didn't work.
There was a problem hiding this comment.
But people use UART's to send and receive binary data, not just to the REPL, and ctrl-C is a valid binary data character. I don't think you want to check at this level of the code.
There was a problem hiding this comment.
I see. I thought I copy-pasted this from another port's code. I will check where this is coming from.
| #include <stdlib.h> | ||
|
|
||
| #include "py/gc.h" | ||
|
|
||
| void *malloc(size_t size) { | ||
| return gc_alloc_possible() ? gc_alloc(size, 0, false) : NULL; | ||
| } | ||
|
|
||
| void free(void* ptr) { | ||
| gc_free(ptr); | ||
| } |
There was a problem hiding this comment.
I don't know why you are doing this instead of using the usual gc alloc routijnes.
There was a problem hiding this comment.
This was just to help port C libraries that rely on malloc from libc. It's not related to streams.
The core of this change is to start using "streams" as a common abstraction for IO. The stream protocol is an existing (though seemingly unused) part of MicroPython. MicroPython streams would be more commonly identified as "file-like objects" in CPython. In this change, audio out devices, files, sockets, and MP3 decoders are all streams.
If you want to jump to the end, this example shows a network streaming MP3 player. The example is not actually async yet because it depends on the socket api being async. And the public Python api is not polished.
The use of streams allows the developer to source their audio data from anywhere. (You can write your own stream-like class in Python.) For example, a network socket, a microphone, and have your own transformers in between (e.g., to change format, demux/reassemble data, observing the raw data).
The behavior of the stream interface (e.g., how blocking, eof, partial transfers are handled) is already specified by CPython. This behavior can be tricky at times, so standardization and reuse are important to facilitate composition across the wide array of modules and devices that CircuitPython supports. In subsequent changes, the stream abstraction will also serve a common entry point for supporting awaitable operations.
Other notes about the change:
audiocoremodule as it is no longer needed. The wav file reader can be implemented in pure Python. And raw samples just becomesBytesIO.audio_dma, the use of background tasks, and the audio buffer protocol.