unable to obtain correct number of samples

[claudio-ortega]

Hi everyone,

I am trying to capture audio with minimum latency (10mSec) using malgo.

I am having a problem.
I am not sure if it is myself making a mistake or I have hit a bug in malgo.
I do not know frankly.

The brief statement is:
-- I am using malgo 0.10.19
-- I need to capture from a predefined device @ 44.1ks/sec, with 16 bits, and 1 channel
-- during a 10 seconds take, the number of bytes obtained is very different from the expected

Details:

The device used as input is being chosen out from the list of available devices produced by malgo itself,
notice that the test selects one of the pre-listed devices.
https://bitbucket.org/claudio_ortega/jambridge2/src/master/src/audio/test/device_capture_test.go

It fills in the config structure with the selected capturing device ID. Then it starts the device, and then it waits for 10 seconds for the capturing device to inject the samples in the callback before stopping the capture and ending the test.

** Expected:
The total number of bytes expected after 10 seconds is something around the theoretical

2*44.1ks/sec*10sec = 882,000 bytes

** Observed:
The config for the device occurs between lines 37 and 44.
The output produced by the test case into the console is in here:
https://bitbucket.org/claudio_ortega/jambridge2/src/master/notes/bug-report.txt
between lines 75 and 128
Notice that the number of bytes obtained is 52800, when the expected is 882000

It might be me making a mistake, that would be great to know.
Can anybody see if I am missing something obvious here?.

[Milan Nikolic]

Hi, I am really the wrapper guy, miniaudio does all magic here, I understand here and there but I don't know the internals and I certainly don't know much about audio. Are there real problems you experience or just numbers do not match? Is there something missing maybe from your formula, why do you expect that e.g. there was a bug with mp3 example, where all it was needed was ReadAll. see here e8a71e7 .

We can ask for help from the author, but better not to bother him if this is not a bug but just a question. If you can browse first through miniaudio code, check, look, verify, and try some examples in C and compare that would be great. Is it a miniaudio or malgo problem is the main question.

[claudio-ortega]

Hi Milan, Thank you for getting back to me, much appreciated. I am happy to answer all questions in your last email. First, a short introduction. I wrote Jambridge in java (see the link in previous emails), which uses a standard java library named soundx. Soundx, like malgo, is a wrapper. Soundx ends up using alsa, coreaudio, ASIO, etc. Jambridge works fine, *except that produces too much delay*, which is around 60-100ms when tested with a network latency of only 10 ms. It should be around 40ms. The delay is not only in the audio layer, there is a component for the delay in the network layer, and I hope the way that Golang interacts with the UDP stack will help me in the right direction on that too. I have decided that at this point is not possible to take the delay down unless I change horses and do the same thing in C or Golang. In my attempt to use Go I am avoiding dealing with C as much as possible. Now, here the answers I owe you: Q1: Are there real problems you experience or just numbers do not match? A1: This is a real problem. If you sample a signal 41000 times per second, for 10 seconds straight, and each sample is worth 2 bytes, then you should get exactly 41000 * 10 * 2 = 882000 bytes. Is that simple, trust me. Now, the problem is that I am getting 52800k bytes, so yes, this is a problem and I would say also an essential one. Q2: .. Try some examples in C and comparing... etc A2: I read all the miniaudio documentation before writing the report. I noticed that the guy just did a big rehaul, so this might be a bug recently introduced. Besides, I am using Golang to not to deal with C other than for the minimum necessary imposed by Cgo, so digging into the C code is something that I want to avoid at all costs. That's why I am using Golang and not C from the start. The last comment, which might be useful to find the root cause: The ratio 882000/52800 is suspiciously close to 16. That might constitute a clue. I already checked that you are not doing any conversion bits to bytes or bytes to bits, samples to bytes, or anything of that sort, so then I do not think the problem is in malgo itself. Hoping this clarifies, My best regards to you, Claudio

…

On Mon, Oct 26, 2020 at 7:58 PM Milan Nikolic ***@***.***> wrote: Hi, I am really the wrapper guy, miniaudio does all magic here, I understand here and there but I don't know the internals and I certainly don't know much about audio. Are there real problems you experience or just numbers do not match? Is there something missing maybe from your formula, why do you expect that e.g. there was a bug with mp3 example, where all it was needed was ReadAll. see here e8a71e7 <e8a71e7> . We can ask for help from the author, but better not to bother him if this is not a bug but just a question. If you can browse first through miniaudio code, check, look, verify, and try some examples in C and compare that would be great. Is it a miniaudio or malgo problem is the main question. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADF4SM6VB2YVTLFUZWJFBGDSMYZNDANCNFSM4S77FP2Q> .

[claudio-ortega]

Milan, My apologies for the typo, wherever I wrote 41000 I meant 44100. Sorry about the confusion that mighty had caused. Claudio On Tue, Oct 27, 2020 at 12:39 PM Claudio Ortega < [e-mail]> wrote:

…

Hi Milan, Thank you for getting back to me, much appreciated. I am happy to answer all questions in your last email. First, a short introduction. I wrote Jambridge in java (see the link in previous emails), which uses a standard java library named soundx. Soundx, like malgo, is a wrapper. Soundx ends up using alsa, coreaudio, ASIO, etc. Jambridge works fine, *except that produces too much delay*, which is around 60-100ms when tested with a network latency of only 10 ms. It should be around 40ms. The delay is not only in the audio layer, there is a component for the delay in the network layer, and I hope the way that Golang interacts with the UDP stack will help me in the right direction on that too. I have decided that at this point is not possible to take the delay down unless I change horses and do the same thing in C or Golang. In my attempt to use Go I am avoiding dealing with C as much as possible. Now, here the answers I owe you: Q1: Are there real problems you experience or just numbers do not match? A1: This is a real problem. If you sample a signal 41000 times per second, for 10 seconds straight, and each sample is worth 2 bytes, then you should get exactly 41000 * 10 * 2 = 882000 bytes. Is that simple, trust me. Now, the problem is that I am getting 52800k bytes, so yes, this is a problem and I would say also an essential one. Q2: .. Try some examples in C and comparing... etc A2: I read all the miniaudio documentation before writing the report. I noticed that the guy just did a big rehaul, so this might be a bug recently introduced. Besides, I am using Golang to not to deal with C other than for the minimum necessary imposed by Cgo, so digging into the C code is something that I want to avoid at all costs. That's why I am using Golang and not C from the start. The last comment, which might be useful to find the root cause: The ratio 882000/52800 is suspiciously close to 16. That might constitute a clue. I already checked that you are not doing any conversion bits to bytes or bytes to bits, samples to bytes, or anything of that sort, so then I do not think the problem is in malgo itself. Hoping this clarifies, My best regards to you, Claudio On Mon, Oct 26, 2020 at 7:58 PM Milan Nikolic ***@***.***> wrote: > Hi, I am really the wrapper guy, miniaudio does all magic here, I > understand here and there but I don't know the internals and I certainly > don't know much about audio. Are there real problems you experience or just > numbers do not match? Is there something missing maybe from your formula, > why do you expect that e.g. there was a bug with mp3 example, where all it > was needed was ReadAll. see here e8a71e7 > <e8a71e7> > . > > We can ask for help from the author, but better not to bother him if this > is not a bug but just a question. If you can browse first through miniaudio > code, check, look, verify, and try some examples in C and compare that > would be great. Is it a miniaudio or malgo problem is the main question. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#24 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ADF4SM6VB2YVTLFUZWJFBGDSMYZNDANCNFSM4S77FP2Q> > . >

[claudio-ortega]

I just tried the same version of my repo for the same test case I reported, but instead of Linux, I tried in my MacBook Pro and... it is producing 846720 bytes, which is pretty close to the expected 882000, this is probably because the device takes it time to start giving samples, sp there it goes another sample point Claudio On Tue, Oct 27, 2020 at 1:26 PM Claudio Ortega < [e-mail]> wrote:

…

Milan, My apologies for the typo, wherever I wrote 41000 I meant 44100. Sorry about the confusion that mighty had caused. Claudio On Tue, Oct 27, 2020 at 12:39 PM Claudio Ortega < ***@***.***> wrote: > Hi Milan, > > Thank you for getting back to me, much appreciated. > I am happy to answer all questions in your last email. > > First, a short introduction. > I wrote Jambridge in java (see the link in previous emails), which uses a > standard java library named soundx. > Soundx, like malgo, is a wrapper. Soundx ends up using alsa, coreaudio, > ASIO, etc. > Jambridge works fine, *except that produces too much delay*, which is > around 60-100ms when tested with a network latency of only 10 ms. > It should be around 40ms. The delay is not only in the audio layer, there > is a component for the delay in the network layer, > and I hope the way that Golang interacts with the UDP stack will help me > in the right direction on that too. > I have decided that at this point is not possible to take the delay down > unless I change horses and do the same thing in C or Golang. > In my attempt to use Go I am avoiding dealing with C as much as possible. > > Now, here the answers I owe you: > > Q1: Are there real problems you experience or just numbers do not match? > A1: This is a real problem. If you sample a signal 41000 times per > second, for 10 seconds straight, and each sample is worth 2 bytes, then you > should get exactly 41000 * 10 * 2 = 882000 bytes. Is that simple, trust me. > Now, the problem is that I am getting 52800k bytes, so yes, this is a > problem and I would say also an essential one. > > Q2: .. Try some examples in C and comparing... etc > A2: I read all the miniaudio documentation before writing the report. I > noticed that the guy just did a big rehaul, so this might be a > bug recently introduced. Besides, I am using Golang to not to deal with C > other than for the minimum necessary imposed by Cgo, so digging into the C > code is something that I want to avoid at all costs. That's why I am using > Golang and not C from the start. > > The last comment, which might be useful to find the root cause: > The ratio 882000/52800 is suspiciously close to 16. That might constitute > a clue. > I already checked that you are not doing any conversion bits to bytes or > bytes to bits, samples to bytes, or anything of that sort, > so then I do not think the problem is in malgo itself. > > Hoping this clarifies, > > My best regards to you, > > Claudio > > > > > > > > > > > On Mon, Oct 26, 2020 at 7:58 PM Milan Nikolic ***@***.***> > wrote: > >> Hi, I am really the wrapper guy, miniaudio does all magic here, I >> understand here and there but I don't know the internals and I certainly >> don't know much about audio. Are there real problems you experience or just >> numbers do not match? Is there something missing maybe from your formula, >> why do you expect that e.g. there was a bug with mp3 example, where all it >> was needed was ReadAll. see here e8a71e7 >> <e8a71e7> >> . >> >> We can ask for help from the author, but better not to bother him if >> this is not a bug but just a question. If you can browse first through >> miniaudio code, check, look, verify, and try some examples in C and compare >> that would be great. Is it a miniaudio or malgo problem is the main >> question. >> >> — >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub >> <#24 (comment)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/ADF4SM6VB2YVTLFUZWJFBGDSMYZNDANCNFSM4S77FP2Q> >> . >> >

[David Reid]

I'm the author of miniaudio. So this error is happening on Linux? I'm assuming you have PulseAudio installed? I just a fixed a couple of bugs with capture mode on PulseAudio, so if you're using PulseAudio it might be worth an upgrade. These are the relevant issue reports - maybe your issue is related? mackron/miniaudio#106, mackron/miniaudio#187. As a test, run your program with pavucontrol open and see if your test runs as expected (random, I know...). If so, it's almost certainly related to those issues and will be fixed when malgo is updated to the latest version.

I think your assertion about the device taking time to deliver data is probably accurate for the macOS case.

[Milan Nikolic]

Thanks, @mackron, I updated malgo to the latest miniaudio version.
Btw. now I see that PA -> ALSA fallback will crash, i.e. if I start playback example as root and it cannot initialize PA, that used to work.

[David Reid]

Hmm, that's annoying. If you disable the PA backend do you get the crash still? Just wondering if it's the PA backend not initializing that's causing the crash or the ALSA backend. Will take a look soon.

[Milan Nikolic]

With just the ALSA backend it works. Here is the gdb output from Go binary with default backends order:

XDG_RUNTIME_DIR (/run/user/1000) is not owned by us (uid 0), but by uid 1000! (This could e.g. happen if you try to connect to a non-root PulseAudio as a root user, over the native protocol. Don't do that.)
LOG <[PulseAudio] Failed to connect PulseAudio context.>

Thread 1 "playback" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00000000004e2f52 in ma_device_start (pDevice=0x6522c0) at miniaudio.h:32821
#2  0x00000000004cc407 in _cgo_f39c4aee37ed_Cfunc_ma_device_start (v=0xc000505b00) at cgo-gcc-prolog:138
#3  0x000000000046da30 in runtime.asmcgocall () at /home/milann/go/src/runtime/asm_amd64.s:656

[claudio-ortega]

Hi David, No complaints from my side, but after days of not hearing back, I started looking for an alternative. I found portaudio, which is working fine for me. Claudio

…

On Mon, Nov 9, 2020 at 12:27 AM David Reid ***@***.***> wrote: I'm the author of miniaudio. So this error is happening on Linux? I'm assuming you have PulseAudio installed? I just a fixed a couple of bugs with capture mode on PulseAudio, so if you're using PulseAudio it might be worth an upgrade. These are the relevant issue reports - maybe your issue is related? mackron/miniaudio#106 <mackron/miniaudio#106>, mackron/miniaudio#187 <mackron/miniaudio#187>. As a test, run your program with pavucontrol open and see if your test runs as expected (random, I know...). If so, it's almost certainly related to those issues and will be fixed when malgo is updated to the latest version. I think your assertion about the device taking time to deliver data is probably accurate for the macOS case. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADF4SM3GMONYQVSOP6NY7PLSO6RXTANCNFSM4S77FP2Q> .

[David Reid]

@gen2brain That should be fixed now. Version 0.10.24.

[Milan Nikolic]

@mackron Updated, thanks.