Closed shoober420 closed 3 years ago
I guess this is my fault, but the best way to fix it without destroying someone else's build is beyond me. I could either add type_compat.h
into asoundlib.h
somehow, or I could change __u8
to uint8_t
, I'm not sure which one is better. Or perhaps some third option.
@tiwai Do you have any suggestion on what the best path forward is?
@diwic : The structure should not be exported outside. See snd_ctl_event_t
for an example.
Admittedly it's a bit exceptional to expose the struct, but I thought this would fit well for the rawmidi use case, as the application so far used only the direct byte stream read without alsa-lib API.
@perexg The structure must be exposed, it's supposed to be used by applications.
@perexg The structure must be exposed, it's supposed to be used by applications.
The data are supposed to be used by apps, but the use may be controlled by alsa-lib like we do for other APIs. I suggest to create a decoder function like:
ssize_t snd_rawmidi_decode_frame(snd_rawmidi_t *rmidi, void *buffer, size_t size,
struct timespec *tstamp, void **frame, size_t *frame_size);
Where buffer
and size
and the undecoded buffer area returned by snd_rawmidi_read
. The return value can be an error code or size of frame (replace SND_RAWMIDI_FRAMING_DATA_LENGTH) and frame
will return pointer to the midi data chunk with the frame_size
length. tstamp
should be allocated by the caller and filled by the decoder.
@perexg I find that to be both more complicated and worse performance, than just reading the struct where it is in memory.
@diwic @perexg I find another issue which caused by the recent rawmidi change. I got alsa-utils build failure on Ubuntu 20.04. After reset to 23a191a, the alsa-utils build fine.
checking for libasound headers version >= 1.2.5 (1.2.5)... not present.
configure: error: Sufficiently new version of libasound not found.
Let's fix the build problem at first. The current definition looks also buggy due to the lack of packed attribute, too.
My objection against the export of this structure persists. The performance issue is negligible with my proposal and I would prefer to follow the other alsa-lib conventions to hide those internal structures. And it's more safe to verify the data consistency in the library rather to open-code the checks (frame_type, length) in applications.
I redesigned the API in https://github.com/alsa-project/alsa-lib/pull/179 .
The recent alsa-lib commit https://github.com/alsa-project/alsa-lib/commit/95eb312fade1908a2c944e9de4626c0ff60b2203 borks OpenAL from building. I thought it was an issue with OpenAL, but he mentions that its an issue with alsa-lib (https://github.com/kcat/openal-soft/issues/592#issuecomment-903211857). Here is the OpenAL build log just in case and a snippet of the OpenAL build error.
https://github.com/kcat/openal-soft/files/7026546/buildopenal.log
OpenAL build error.