Skip to content

Minor fixes to miniaudio for kew compatibility#1095

Closed
ravachol wants to merge 1 commit into
mackron:devfrom
ravachol:feature/kew-fixes
Closed

Minor fixes to miniaudio for kew compatibility#1095
ravachol wants to merge 1 commit into
mackron:devfrom
ravachol:feature/kew-fixes

Conversation

@ravachol

@ravachol ravachol commented Feb 7, 2026

Copy link
Copy Markdown

While working on kew I ran into a few problems that I fixed in miniaudio.h. I'm making this PR to provide you with these fixes. You don't need to include them of course, but it would make life easier for us, because our package managers would be able to use miniaudio as an external dependency instead of vendoring without issue.

The fixes included are:

  1. call to MultiByteToWideChar:
    sizeof(filenameW) returns the total size of the buffer in bytes (4096 bytes)
    but MultiByteToWideChar is expecting wide characters (wchar_t), not bytes.
    Solution: divide by sizeof(WCHAR)

  2. Added read error check in static ma_result ma_device_stop__alsa(ma_device* pDevice)
    The original code checks if the number of bytes read (resultRead) is not equal to the expected number of bytes (sizeof(t))
    However, it doesn't handle the possibility of an actual read() error. read() can return -1. This check has been added with a call to perror. This might not be exactly how you'd like to handle it, but I have included it in any case.

  3. Added default value
    ma_uint64 framesProcessed;
    changed to:
    ma_uint64 framesProcessed = 0;
    in MA_API ma_result ma_data_source_read_pcm_frames(ma_data_source* pDataSource, void* pFramesOut, ma_uint64 frameCount, ma_uint64* pFramesRead)

  4. Fix potential division by 0 error
    int frame_bytes = ma_dr_mp3_hdr_frame_samples(h)*ma_dr_mp3_hdr_bitrate_kbps(h)*125/ma_dr_mp3_hdr_sample_rate_hz(h);
    changed to:
    unsigned int sampleRate = ma_dr_mp3_hdr_sample_rate_hz(h);
    if (sampleRate == 0) return 0;
    int frame_bytes = ma_dr_mp3_hdr_frame_samples(h)*ma_dr_mp3_hdr_bitrate_kbps(h)*125/sampleRate;

  5. Return if userdata is null
    if (pMP3->pUserData == NULL)
    return 0;
    added to static size_t ma_dr_mp3__on_read(ma_dr_mp3* pMP3, void* pBufferOut, size_t bytesToRead)

That's it!

@mackron

mackron commented Feb 7, 2026

Copy link
Copy Markdown
Owner

Thanks.

  1. This is fine. Good catch. Though typically I would use ma_countof(), but this is fine.

  2. I'm not seeing what this is actually fixing. sizeof(t) is always 8. The resultResult == -1 will naturally be caught in the resultRead != sizeof(t) because -1 != 8. I'm not accepting this change.

  3. This is mostly fine. I think a better fix to initialize it to zero at the top of ma_data_source_read_pcm_frames_within_range() which is the standard miniaudio way of doing it.

  4. I'm not so sure about this one. Looking at the implementation of ma_dr_mp3_hdr_sample_rate_hz() I can't see how this is returning zero. The lookup into the array is guarded at a higher level with ma_dr_mp3_hdr_valid(). Was this found by static analysis? If not and there is a specific file that is triggering an error I'd be interested in taking a copy so I can verify this myself. If there is no repro file then I won't be accepting this change.

  5. This is invalid. The user data pointer should always be passed straight through without being touched or looked at in any way. This will break cases when the user data is explicitly set to the NULL by intention.

I won't be merging this PR as is, but I'll address 1 and 3 manually. Will leave this open as a reminder.

@ravachol

ravachol commented Feb 8, 2026

Copy link
Copy Markdown
Author

Regarding 4 I must have gotten a zero there at some point, or I wouldn't have discovered it, but it could of course have been found while some changes to kew were a work in progress due to a bug in kew. Next time I'll try to upstream these/let you know as soon as I find them, while everything is fresh in memory.

mackron added a commit that referenced this pull request Feb 14, 2026
mackron added a commit that referenced this pull request Feb 14, 2026
@mackron

mackron commented Feb 14, 2026

Copy link
Copy Markdown
Owner

1 and 3 have been addressed manually in the dev branch. For the MP3 thing, if that's ever replicated feel free to submit a separate ticket.

@mackron mackron closed this Feb 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants