You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand that gfxprim's goal is to be focused on the low-level graphics layer, but what are your thoughts on a low-level audio buffer wrapper? I've seen what you put together with gpplayer and really like what you've put together.
Something that would provide an interface, along with an alsa-device backend? Likely out of scope for gfxprim, but wanted to get your thoughts. Some of audio_output.c, split across an alsa backend, and a gfxprim-audio interface.
The text was updated successfully, but these errors were encountered:
I guess that gpplayer is not the only application that will use audio output and alsa is complicated beast, so it would make sense to put the simplified API for sound sink and mixer somewhere. I guess that even adding include/audio and libs/audio/ into gfxprim wouldn't be that bad.
hi maybe both of you must take more attention on the working and portability and let audio (a complicated topic way due changes in linux and related unix ports) aside for later days
I understand that gfxprim's goal is to be focused on the low-level graphics layer, but what are your thoughts on a low-level audio buffer wrapper? I've seen what you put together with gpplayer and really like what you've put together.
Something that would provide an interface, along with an alsa-device backend? Likely out of scope for gfxprim, but wanted to get your thoughts. Some of audio_output.c, split across an alsa backend, and a gfxprim-audio interface.
The text was updated successfully, but these errors were encountered: