generate downmixed stereo buffer for Windows #668
Conversation
|
After checking on my second computer, I saw that 24-bit seems to be common as well, so I added downmixing for that format. In further testing there was inconsistency if cava was not fed 16-bit, so I added conversion for mono and stereo 24 and 32-bit as well. Another thing I did learn is that Dolby Atmos, DTS:X, basically anything with Spatial processing enabled is not available via loopback. So getting that to work would either require developing an audio driver to ship with cava or utilizing third-party software to handle audio mixing and virtual cables. As it stands right now, cava freezes if fed Dolby Atmos. It seems to handle a failure properly and print that the device is not supported but then locks up. I'll see if I can determine more at a later time. |
|
hi @theeternalsw0rd. A lot of stuff going on here I can see! I'm afraid I don't have time to go through it in detail, but browsing through it looks like you have added a lot of converting that I don't understand. cava is supposed to handle s8, s16, s24 and float both mono and stereo. But you have added stuff like "convert_mono_f32_to_s16". Maybe the mono processing in cava is not working? If cava is not working when not fed 16 bit stereo, than that needs to be fixed in cava. down/up mixing: https://github.com/karlstav/cava/blob/master/input/common.c#L21 stereo/mono handling is happening around here: https://github.com/karlstav/cava/blob/master/cavacore.c#L362 |
|
I've pulled the conversion of stereo and mono out. Turns out the issue my previous refactor resolved that had to do with the graph freezing before reaching zero level when going from audible audio to silence, also resolved the issue with non-16-bit audio. Quite bizarre. |
input/winscap.c
Outdated
|
|
||
| write_to_cava_input_buffers(silent_channels, (unsigned char *)silence, audio); | ||
| pCapture->lpVtbl->ReleaseBuffer(pCapture, numFramesAvailable); | ||
| pCapture->lpVtbl->GetNextPacketSize(pCapture, &packetLength); |
There was a problem hiding this comment.
is it maybe just packetLength here, without the &?
There was a problem hiding this comment.
or maybe better remove the * from the write_silent_frame packetLength function argument and remove the & when calling the function.
|
That’s probably it. I think I already corrected that in another method using the former solution. I’ll make sure it’s consistent using the latter.
Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: karl ***@***.***>
Sent: Thursday, July 31, 2025 2:53:59 PM
To: karlstav/cava ***@***.***>
Cc: Micah Bucy ***@***.***>; Mention ***@***.***>
Subject: Re: [karlstav/cava] generate downmixed stereo buffer for Windows (PR #668)
@karlstav commented on this pull request.
________________________________
In input/winscap.c<#668 (comment)>:
@@ -132,6 +304,44 @@ struct {
{AUDCLNT_E_UNSUPPORTED_FORMAT, L"Requested sound format unsupported"},
};
+void write_silent_frame(struct audio_data *audio, IAudioCaptureClient *pCapture,
+ UINT32 numFramesAvailable, UINT32 *packetLength) {
+ // Send one silent frame to the spectrometer
+ int silent_channels = audio->channels;
+ int silent_bytes = silent_channels * sizeof(int16_t); // 16-bit PCM
+ int16_t silence[2] = {0};
+
+ write_to_cava_input_buffers(silent_channels, (unsigned char *)silence, audio);
+ pCapture->lpVtbl->ReleaseBuffer(pCapture, numFramesAvailable);
+ pCapture->lpVtbl->GetNextPacketSize(pCapture, &packetLength);
or maybe better remove the * from the write_silent_frame packetLength function argument and remove the & when calling the function.
—
Reply to this email directly, view it on GitHub<#668 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAGAZMKO73APANKBIK6CWYT3LJQ4PAVCNFSM6AAAAACCPHNR5KVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTANZWGU3DMMBZGA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
20-bit audio is also used it seems. I've set up a separate branch for that since I cannot test it currently. I'll try to locate some hardware to test on. I think the virtual cable I have at work supports it, so I can check that tomorrow. The changes for the use of packetLength have been pushed. |
|
I did find a device that supports 20-bit audio, but that format is not selectable in Windows 11 sound settings. Windows itself may have removed support completely or 20-bit is only available via direct hardware or the audio driver isn't properly sending supported formats to Windows. I will not worry about it at this point. It's available on my repo under the 20-bit branch if anyone should have need. I am assuming anything with 20-bit support also supports other formats too. |
|
just use the .clang-format file to make the linter happy. don't worry about the commits, I will squash them when i merge |
|
Hopefully the linter is happy now. I made the handling of overflowing lines as consistent as possible across the board too. |
|
Sorry, didn't realize the linter failure actually generates a patch that it would be happy with. I'll get that applied. I guess the reason for the inconsistent long line formatting is the linter itself being at fault. |
|
The linter supplied patch has been applied. Hopefully now it should have no reason to complain. |
2 participants
Always feed a buffer of at most 2 channels to cava regardless of audio output to device. There may still be edge cases that need covered where it has the comment // Unsupported format, handle error (line 405). This handles 16-bit pcm multichannel, 32-bit pcm multichannel, and 32-bit floating point multichannel.