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

[PKTKS]

Standard DMIX plugin 

Code: [Select]

pcm.FLOATCNVT {
type dmix
ipc_key 2048
ipc_key_add_uid 0
ipc_perm 0660
slave {
pcm { type hw card 0 }

format "FLOAT_LE"
rate 96000
channels 2
}
bindings {
0 0
1 1
}
}

ctl.FLOATCNVT {
type hw
card 0
}

Paul

This is exactly what plughw is already doing

ALSALIB will parse the defined configures at any call.

Unless you have them defined - it will not magically fall from the sky...

It must be defined somewhere. Or... written in the command line

Paul

[RoGeorge]

To my ubuntu 20.04, arecord with plughw: (or sox, or ffmpeg) gives a much slower refresh in baudline making it all jumpy, than using hw: and converting to float with C.

It sounds like you have a larger issue at hand, I am getting real-time, smooth output even at 96kHz no matter how I feed baudline.

As a test, do you get smooth framerates if you feed it /dev/urandom instead? If so you have an issue with your sound device, perhaps your period size/count is not dealing well and you need to tune this some.

Further to this, what is your sound device?

Not sure how to feed data, do you have an example of the command, please?

Couldn't make arecord to read from /dev/urandom or from stdin, and if you mean to test by feeding /dev/ramdom to baudline, directly, if I do this:

Code: [Select]

cat /dev/urandom | bl -format le32f -samplerate 96000
# bl is an alias for "baudline_1.08_linux_x86_64/baudline -stdin -record -channels 2 "then cat will flood too much data into baudline, making baudline unresponsive.

I guess some larger buffers come into play inside arecord (or sox or ffmpeg) when using plughw: instead of hw:

Otherwise it all seems to be working fine, baudline shows about 60fps+ and fluid move (the monitor is 60Hz and the driver syncs to that to avoid video tearing).

The soundcard is an onboard Sound Core3D Recon 3D internal (ca0132 chipset from Creative, the followup of emu10k1/2, Audigy, etc.), MB ASRock Fatal1ty Z97 Professional, nVidia GTX760/2GB, i7-4790K, 32GB RAM, SSD.

[PKTKS]

Not sure how to feed data, do you have an example of the command, please?

Couldn't make arecord to read from /dev/urandom or from stdin, and if you mean to test by feeding /dev/ramdom to baudline, directly, if I do this:

Code: [Select]

cat /dev/urandom | bl -format le32f -samplerate 96000
# bl is an alias for "baudline_1.08_linux_x86_64/baudline -stdin -record -channels 2 "then cat will flood too much data into baudline, making baudline unresponsive.

I guess some larger buffers come into play inside arecord (or sox or ffmpeg) when using plughw: instead of hw:

Otherwise it all seems to be working fine, baudline shows about 60fps+ and fluid move (the monitor is 60Hz and the driver syncs to that to avoid video tearing).

There seems to be a necessary climbing of some steps....

the use of  ALSA LIB  plugins is straight  like  -D plug:[ANY_DEFINED_PLUG_THING]

But...   your system REQUIRE  the proper  CARD DEFINITIONs  and  NODES (which mostly are messed and subverted by systemd and other problems...)

Basically you just invoke  aplay or arecord with the required config plugin

I have some dozens plugins defined to handle al sort of complex things...
including AUDIO ROUTING..  when not using JACK


Paul

[gnif]

Not sure how to feed data, do you have an example of the command, please?

Couldn't make arecord to read from /dev/urandom or from stdin, and if you mean to test by feeding /dev/ramdom to baudline, directly, if I do this:

Code: [Select]

cat /dev/urandom | bl -format le32f -samplerate 96000
# bl is an alias for "baudline_1.08_linux_x86_64/baudline -stdin -record -channels 2 "then cat will flood too much data into baudline, making baudline unresponsive.

I guess some larger buffers come into play inside arecord (or sox or ffmpeg) when using plughw: instead of hw:

Otherwise it all seems to be working fine, baudline shows about 60fps+ and fluid move (the monitor is 60Hz and the driver syncs to that to avoid video tearing).

Ah yes, sorry about that, I forgot that the audio device will be rate limiting the input. In any case, I still suspect an issue with your capture method/configuration. What is your sound device?

[gnif]

Not sure how to feed data, do you have an example of the command, please?

Couldn't make arecord to read from /dev/urandom or from stdin, and if you mean to test by feeding /dev/ramdom to baudline, directly, if I do this:

Code: [Select]

cat /dev/urandom | bl -format le32f -samplerate 96000
# bl is an alias for "baudline_1.08_linux_x86_64/baudline -stdin -record -channels 2 "then cat will flood too much data into baudline, making baudline unresponsive.

I guess some larger buffers come into play inside arecord (or sox or ffmpeg) when using plughw: instead of hw:

Otherwise it all seems to be working fine, baudline shows about 60fps+ and fluid move (the monitor is 60Hz and the driver syncs to that to avoid video tearing).

There seems to be a necessary climbing of some steps....

the use of  ALSA LIB  plugins is straight  like  -D plug:[ANY_DEFINED_PLUG_THING]

But...   your system REQUIRE  the proper  CARD DEFINITIONs  and  NODES (which mostly are messed and subverted by systemd and other problems...)

Basically you just invoke  aplay or arecord with the required config plugin

I have some dozens plugins defined to handle al sort of complex things...
including AUDIO ROUTING..  when not using JACK


Paul

Please just stop, as mentioned in another thread, I am not just some general Linux user, I am both a kernel developer and one of my specialities is the Linux audio subsystems. I have written both audio drivers, user space audio applications, DSP chains and full audio pipelines/engines for applications. I am a contributor to some of the largest and most widely used FOSS projects that make use of audio under Linux and the author of the audio engine used by Kodi (formally XBMC) where we ripped out all the ALSA asoundrc junk in favour of directly using alsalib correctly. I am currently working on a DSP processing tool for general desktop users that does real time processing of audio without JACK, etc... your claim is nothing special.

[RoGeorge]

The soundcard is an onboard Sound Core3D (Recon3D internal ?) (ca0132 chipset from Creative, the followup of emu10k1/2, Audigy, etc.), MB ASRock Fatal1ty Z97 Professional, nVidia GTX760/2GB, i7-4790K, 32GB RAM, SSD.

It is known as buggy, long cumbersome history, with drivers windows only then Creative open sourced later the drivers from some other descendent chip (ca0100) and somebody took the time to sniff the messages exchange between the Windows driver and the Windows OS, then he crafted the ca0132 Linux driver.

Only a week ago I was trying to modify the drivers and recompile, but if nobody bothered fixing all that in the last 10 years, then maybe it's not worth doing it, or maybe is not even possible.

Here's a list of bugs I'm seeing:
https://www.eevblog.com/forum/programming/audio-in-linux/msg4308922/#msg4308922

And this is the github repo (inside another topic that might add details about this particular driver, but please keep in mind I was having no idea what I was doing/writing/testing there):
https://www.eevblog.com/forum/programming/compile-a-linux-kernel-module/msg4327933/#msg4327933

Connor McAdams is the one who reversed engineer all then wrote the ca0132 patch for Linux.
This is his hda patch for ca0132 chip:  https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_ca0132.c

[gnif]

The soundcard is an onboard...

This is all I needed to see . Onboard sound devices are notorious for issues like that which you are seeing here, they commonly suffer from interrupt jitter which causes latency issues. If your device is getting into an under/overrun state it can cause stream stalls while it get's reinitialised by alsalib (DMA xfers stop and have to be re-started). Unfortunately when using `arecord` it's impossible to determine when/if these stalls are occurring.

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`.

The buffer-size is a multiple of the period-size, so to have two periods you would want buffer-size to be 2x the period-size. The minimum periods you can run with is usually 2, but some cards (like onboard) need 3 or more. If this doesn't help also increase your buffer-size. Keep it to powers of 2, for example:

period-size=512
buffer-size=1024

Play with these values and see if it helps your use case. Obviously the larger the buffers, the more latency that will be introduced, however for your use case I don't think that this matters much.

[PKTKS]

I ve place to important  tips for properly setting device nodes...

They have been erased....  reason being unknown...

Anyway the tip still holds:  The OP has issues with the system nodes
unless he can properly fix them.. it will be hard to achieve proper ALSA goals.

Posted how nice a CRAPPY ON BOARD MOBO can perform at DAW level this days.. (including low latency MIDI resonse with real time scoring )

also erased...  so ... I rather mention for those who can see how the tips are relevant
to contact me off topic..

anyone welcome . as usual

Paul

[gnif]

I ve place to important  tips for properly setting device nodes...

They have been erased....  reason being unknown...

Off topic and outside the scope of the problem, this is not a full DAW and does not have the issues you are describing. Audio nodes as you understand them are not part of this issue when talking to the hardware directly via `hw` or `plughw`. The issue is the application `baudline` is having a framerate issue when the audio source is coming from arecord, but for some reason the issue is somewhat resolved when coming via another process, this indicates that additional buffering (via stdio) is resolving this problem to a minor extent and points at period counts and buffer sizes being the issue along with the low quality integrated audio solution of the system.

Posted how nice a CRAPPY ON BOARD MOBO can perform at DAW level this days.. (including low latency MIDI resonse with real time scoring )

also erased...  so ... I rather mention for those who can see how the tips are relevant
to contact me off topic..

MIDI has no relationship at all with PCM, completely off topic.
Last warning, stop posting off topic things and over-complicating an issue that is already being diagnosed.

[PKTKS]

I ve place to important  tips for properly setting device nodes...

They have been erased....  reason being unknown...

Off topic and outside the scope of the problem, this is not a full DAW and does not have the issues you are describing. Audio nodes do not play a part when talking directly to the hardware via `hw` or `plughw`.

Posted how nice a CRAPPY ON BOARD MOBO can perform at DAW level this days.. (including low latency MIDI resonse with real time scoring )

also erased...  so ... I rather mention for those who can see how the tips are relevant
to contact me off topic..

MIDI has no relationship at all with PCM, completely off topic.
Last warning, stop posting off topic things and over-complicating an issue that is already being diagnosed.

They just do.

Unless properly set the applications will not find them...

and  i am guessing that in the OP case... he has a void node being read from the PIPE.

Paul

[gnif]

They just do.

The MIDI device will not even be open! far out, learn how ALSA works, the PCM device is what is in use here, stop polluting this thread.

https://github.com/alsa-project/alsa-utils/blob/master/aplay/aplay.c#L829

err = snd_pcm_open(&handle, pcm_name, stream, open_mode);

Is not `snd_rawmidi_open`

[PKTKS]

They just do.

The MIDI device will not even be open! far out, learn how ALSA works, the PCM device is what is in use here, stop polluting this thread.

My dear... of course  MIDI has not been the OP issue.

But it is a very important issue TO SETUP THE WHOLE SYTEM NODES.

I ve posted how a cheap crap on board mobo CAN PERFORM REAL TIME..

AUDIO AND MIDI AND SCORING in real time..

YOU probable erased..  and threats to myself will not  change the issue.

The system must be  set... the nodes must be valid..

AND ... real time performance will be fine..

If you feel fine to insult me and ban me go ahead...

It seems to be your goal..

Paul

[magic]

To my ubuntu 20.04, arecord with plughw: (or sox, or ffmpeg) gives a much slower refresh in baudline making it all jumpy, than using hw: and converting to float with C.  Found the -scaleby parameter in baudline, thought that would be a strange number to remember 1/65536=0.0000152587890625, so conversion with C is more convenient and doesn't slow down the framerate.

Don't think so.

If the floating point samples are in the domain {-1., +1.} then the proper scaling command would be "-scaleby 32767."

I don't know what "slow down the framerate" means; it's probably some buffering problem - not enough or too much?.
I would start with recording something to file and tweaking those buffer/period options until the recording comes out right.

If WAV files record right but piping the same data into baudrate doesn't, then maybe you need more buffering. Perhaps insert cat between them?

[gnif]

But it is a very important issue TO SETUP THE WHOLE SYTEM NODES.

  By using `hw` or `plughw` you bypass the entire asound system and take direct control of the hardware device.... it BYPASSES the system you're talking about. Again learn how the ALSA subsystem works,

https://github.com/torvalds/linux/blob/20cf903a0c407cef19300e5c85a03c82593bde36/sound/core/pcm_native.c#L2820

`snd_pcm_open` calls directly into the kernel and when we use `hw` there is a direct line to the hardware, NOTHING IN THE MIDDLE.

[PKTKS]

ok my dear..  i take none of your insults...

Facts still remain...    you remind me my 7y old bonehead nephew...

Impossible just so..

GO ahead delete my stuff and  ban me ....    nothing prevents you..

erasing my posts will not change facts.

My stuff is working flawless based on what you think wrong

Paul

[gnif]

If you feel fine to insult me and ban me go ahead...

It seems to be your goal..

If it were my goal you would already be banned mate. I have stated several times now to stop posting your suggestions here because they are WRONG. I have 15 years of experience with ALSA and how the internals of it work, including the emu10k core that the OPs sound card is loosely based on, along with the issues that it had when creative stopped support of it.

ok my dear..  i take none of your insults...

I have not insulted you once.

Facts still remain...    you remind me my 7y old bonehead nephew...

Yet here you are insulting me

Impossible just so..

GO ahead delete my stuff and  ban me ....    nothing prevents you..

Except the fact that I have been trying to give you a fair chance...

erasing my posts will not change facts.

They will remove useless information that has no bearing on this issue.

My stuff is working flawless based on what you think wrong

EXACTLY, YOURS
YOUR SETUP
YOUR HARDWARE
YOUR CUSTOM KERNEL,
YOUR CUSTOM REQUIREMENTS
YOUR DAW SETUP.

This is NOT what the OP has, nor what the OP is dealing with, nor does the OP need real time processing as is needed in a DAW setup.

Final warning, I have been more than fair here.

[PKTKS]

You already  deleted so much relevant stuff...

to twist support your point and make me look like a rant idiot...
Included some hard to find clues...

Anyone reading this crippled (by you) posts will have a hard time to understand.
Nevertheless.  Anyone interested is very welcome to contact me with such issues.

I have not much to add...as half you deleted...

It  adds up even being worst than ban.. being crippled by twisted deformed opinions

Paul

[gnif]

You already  deleted so much relevant stuff...

to twist support your point and make me look like a rant idiot...
Included some hard to find clues...

Anyone reading this crippled (by you) posts will have a hard time to understand.
Nevertheless.  Anyone interested is very welcome to contact me with such issues.

I have not much to add...as half you deleted...

It  adds up even being worst than ban.. being crippled by twisted deformed opinions

Paul

Keep stating this crap, we do not delete posts but move them to a deleted topic where all moderators and server admins can see the full history.  I have posted exactly why you are wrong and provided proof positive of your misinformation in both the ALSA sources and the Linux kernel itself and removed your posts you posted AFTER I told you to stop because it's miss-information and is not helpful here.

As for your deleted posts, you offered a few screenshots and a script... none of the information provided was useful in any meaningful sense. The issue here is a buffering/interrupt issue, it may even be an issue with the baudline application itself, we have not yet isolated the exact cause, but your continual insistence that its the configuration of a subsystem we have bypassed entirely is just idiotic.

[PKTKS]

You stated very well:

- i HAVE MY STUFF (  kernel, DAW etc_etall ) working fine.

I just have no other way to put examples to the OP or anyone else...

Can you image a better example than a FULLL WORKING SYSTEM..

You deleted them and still threat me to your biased already conceived point.

My examples hold just true.. working fine.. and *ANYONE* can duplicate them..

point is .. you deleted them...

What is it??  it bothers you?   you feel envy?  threats make you feel good?

Paul

[gnif]

- i HAVE MY STUFF (  kernel, DAW etc_etall ) working fine.

So you think the OP has the same sound device as you with the same buffering configuration, the same IRQ patterns, the same codecs, and all your configurations apply to his device also?

Can you image a better example than a FULLL WORKING SYSTEM..

Yes, one that matches the OPs hardware and replicates his issue so it can be properly diagnosed.

I have had enough, you have had enough warnings.
Edit: PKTKS temp banned for 3 days

[Nominal Animal]

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`.

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]

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`.

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.)

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 ( ), 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]

I'm sorry to see bans because of my topic. 

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.