Products > Programming

[SOLVED] 24bits/96kHz conversion of s32le to f32le in a stdout to stdin pipe?

<< < (10/11) > >>

Nominal Animal:

--- Quote from: gnif on August 08, 2022, 01:55:53 pm ---The reason why the C application in the pipeline is avoiding this issue somewhat is due to buffering. I suggest you have a play with different period sizes and buffer sizes with arecord. I see you were specifying the`-B` switch which sets the buffer time, but this doesn't control the number of buffers. The flags to play with are `--period-size` and `--buffer-size`.
--- End quote ---
That's exactly why I wrote my suggested converter like I did: it does the minimum number of read syscalls to obtain the data already in the pipe that consists of an integer number of convertable samples, up to a compile-time maximum number of samples, and immediately forwards the converted data.  Should yield minimum latency, but will be affected by those arecord options.

If one uses <stdio.h> fread()/fgetc()/getc()/getchar()/fwrite()/fputc()/putchar(), then the standard C library will add its own software buffers in between.

While I do approve of the Unix philosophy, and chaining tools to get complex stuff done, when they start interfering with the task at hand (like dropping data), it is time to write a better tool, methinks.

I already have written a clunky VU meter program for Ed Kloonk on top of ALSA in a different thread around here somewhere, that could be easily modified to do e.g. DFT on the raw data using just ALSA and FFTW3 libraries (and Gtk+3 for the UI, if desired).  Then, the optimum buffer/period size would be either one or one half DFT/FFT window (depending on the desired overlap and windowing function).  This stuff isn't difficult, except when you are also fighting against hardware or its drivers... (or are a burned out husk of a man like I am, I guess; which is why I never finished that program for Ed.  Sorry, Ed.)

gnif:

--- Quote from: Nominal Animal on August 08, 2022, 03:37:30 pm ---
--- Quote from: gnif on August 08, 2022, 01:55:53 pm ---The reason why the C application in the pipeline is avoiding this issue somewhat is due to buffering. I suggest you have a play with different period sizes and buffer sizes with arecord. I see you were specifying the`-B` switch which sets the buffer time, but this doesn't control the number of buffers. The flags to play with are `--period-size` and `--buffer-size`.
--- End quote ---
That's exactly why I wrote my suggested converter like I did: it does the minimum number of read syscalls to obtain the data already in the pipe that consists of an integer number of convertable samples, up to a compile-time maximum number of samples, and immediately forwards the converted data.  Should yield minimum latency, but will be affected by those arecord options.

If one uses <stdio.h> fread()/fgetc()/getc()/getchar()/fwrite()/fputc()/putchar(), then the standard C library will add its own software buffers in between.

While I do approve of the Unix philosophy, and chaining tools to get complex stuff done, when they start interfering with the task at hand (like dropping data), it is time to write a better tool, methinks.

I already have written a clunky VU meter program for Ed Kloonk on top of ALSA in a different thread around here somewhere, that could be easily modified to do e.g. DFT on the raw data using just ALSA and FFTW3 libraries (and Gtk+3 for the UI, if desired).  Then, the optimum buffer/period size would be either one or one half DFT/FFT window (depending on the desired overlap and windowing function).  This stuff isn't difficult, except when you are also fighting against hardware or its drivers... (or are a burned out husk of a man like I am, I guess; which is why I never finished that program for Ed.  Sorry, Ed.)

--- End quote ---

Indeed, which is why I believe arecord piped to the tool should also work fine if the buffering parameters are adjusted, but in reality we are at the mercy of the drivers and whatever the closed source `baudline` application is doing with the data as it takes it... I mean, `baudline` itself may be stalling due to some other factor for just long enough to cause a problem due to other workloads on the system, etc.

While I can make it work fine for me, on my "unconfigured nodes" system ( :-DD), my hardware is very very different from the OPs hardware, and as such all factors must still be considered.

gnif:
Playing more with baudline, seems there are some stats you can obtain that might be useful (attached).
Right click and select `stats`, see if the video FPS and transforms/sec remains stable, it might help indicate if you have a general system performance issue with this workload.

RoGeorge:
Yes, noticed it, the 60+ fps I was writing to have when pipe-ing with C is from the baudline's stats 'menu'.

Just to be sure I'm not misleading, the whole sound works OK in audio/video play, and record, and all the daily use of the desktop.

The choppy thing of 5fps-like only happens while measuring the spectrum with baudline, and it does not affect anything else except the spectrum image rolling in baudline.  Movies or audio plays fine at the same time with a choppy spectrogram in baudline.
 
I guess the same, some buffering problem specific to baudline only, except it doesn't worth investigating since I can just avoid it by pipe-ing through the C converter.

This is all hobby level, curious to see baudline plots with 24bits and how they differ from the ones in 16 bits, which thanks to everybody's help here, now I've learn how to do that.  I'm sorry to see bans because of my topic.  :-[

gnif:

--- Quote from: RoGeorge on August 08, 2022, 05:04:26 pm ---I'm sorry to see bans because of my topic.  :-[

--- End quote ---

Not your fault mate, don't feel bad. Unfortunately Linux audio is one of those topics that has a million "experts" but very few actual engineers. Thankfully you have had help from those that understand the issue here and have found you a workable solution.

If you feel this is solved I will lock this thread to prevent it being necro'd when PKTKS is able to participate again.

Btw, I have spent a bit of time trying to replicate your fault and I have found no combination of configurations that trigger it.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod