@patricklang For me Ableton's Glue sounds better even than actual hardware SSL because that is the sound where I learned about feedback compression :-) So it is kind of choice between my "reference" or something else when it comes to that compressor. Good in sound is a lot what you are used to as good.

@patricklang My point of view of many of the new features: it's cool that there is stock option but if there is already functional plugin it is not in the end as useful as these small workflow optimizations... E.g. cool that there is 909 and pitch shifter but you cannot level up much with those.

E.g. not that long ago Compressor+ came with glue compression (feedback input signal) but after trying out different settings I still cannot dial it as well as https://cytomic.com/product/glue/, which I bought after switching to Bitwig because Live's Glue was so great (and it's the same same). It does not need a lot in color that you just don't like it as much...

Stepwise is also great because in the past you could emulate Effectrix with a complex Grid patch but it was not that practical. But now with Stepwise and "In any Grid patch, parsing each lane's stream" you can actually make that kind of thing also as usable as Effectrix...

what is this https://atarihotels.com/

@patricklang Yeah, a huge workflow improvement IMHO.

Actually working on a blockchain node implementation on the other hand drives me purely by challenge because I don't know anything about the topic.

In addition to loopback driver for v4l2 I'm also working still on TPM2 signers patch set for asymmetric keys. Both are off-work business :-) I enjoy working with kernel now like this because I can do features based on my own needs, not on corporate needs... Thus also features are rare because I don't get anything out of doing something if I don't have need for it. Challenge by itself does not drive me for some reason (unless someone offers me money for doing a feature).

I ended up ordering 9990X based machine, which I will later upgrade during its life-cycle to 9990X3D. Should be enough power for my needs in kernel and Rust...

First machine I bought "as a company" as I'm working as a contractor and first machine with water cooling ;-)

It's a custom build from local computer shop with 24 month full service for replacing parts etc. (so I don't have to do that).

BItwig Studio 5.3 will have the feature I've wanted to any DAW for ages: accented notes in the piano roll. So that you can use two logical velocities and then just put them into good values. A HUGE time saver...

From all the features listed, accented notes is my favorite. Wanted it for so long...

https://downloads.bitwig.com/5.3%20Beta%201/Release-Notes-5.3-Beta-1.html

#bitwig #musicproduction

Writing down this for myself for the most part to get idea what to write to the cover letter later on.

My RFC driver model for v4l2-loopback will be centered around /dev/video_loop. It has only single ioctl (OOT driver has three), which has N input parameters (describing metadata for the video device) and exactly two output parameters:

1. capture_fd: communications end point for the virtual capture device. Created using anonymous inode.
2. output_nr: /dev/video{output_nr} is the V4L2 device for the output.

There is no query ioctl because any sane program should at minimum know what resources it creates and should not have privilege in the first place to peak others resources.

There is no remove ioctl because close(capture_fd) destroys /dev/video{output_nr}

Neither overlay nor dma-buf support in the initial version (should be reviewed from basis that these can be extended later on).

#linux #kernel #video4linux #v4l2loopback

@oleksandr A driver model where fd represents a capture device and state change by writes to that descriptor.

So yeah I ripped OTT drive off and now I'm stripping it off :-)

I realized that e.g. tpm_vtpm_proxy and also SGX driver have some innovations in device management that I can re-use that code and combine it with innards of the OTT driver.

So I'm going through this slow process right now: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=v4l2-loopback-dev

Once I have something that make sense I rewrite all device management shenanigans. That will result an RFC patch :-)

@oleksandr I'm making RFC patch set of in-kernel driver...

Factor out the core code from this and wrap it with better driver model.

Getting camera when using Google Meet is a great motivator:

$ git -P log --oneline master..
4443634cf761 (HEAD -> v4l2-loopback-dev, origin/v4l2-loopback-dev) media: v4l2-loopback: Open code "max_buffers"
2675a7f243a9 media: v4l2-loopback: Reorganize constants
c2b256ea51a0 media: Remove V4L2L_OVERLAY code path
2518279c3788 media: Remove !V4L2LOOPBACK_WITH_STD code path
0d8d5155c6ab media: Open code v4l2l_pix_format_has_valid_sizeimage()
c5e199b864fe media: v4l2-loopback: Replace dprintk() with pr_debug()
75cc3a15ccf0 media: v4l2-loopback: Remove the parameter "debug"
36ae93bcb2d7 media: v4l2-loopback: Remove v4l2l_mod64()
0cf1e2192918 media: v4l2-loopback: Remove sysfs shenanigans
520e4971b347 media: v4l2-loopback: Remove dprintkrw()
1670e49b1d28 media: v4l2-loopback: Remove MARK()
8c6389ba1e2b media: v4l2-loopback: Remove MODULE_VERSION()
1a50af7267ae media: v4l2-loopback: Remove SNAPSHOT_VERSION code path
3d21bcb22993 media: v4l2-loopback: Remove MODULE_AUTHOR()
986380446e78 media: v4l2-loopback: Remove LINUX_VERSION_CODE checks
2929a5908be8 media: v4l2-loopback: Remove !HAVE_TIMER_SETUP code path
c7a76fbfd8f3 media: v4l2-loopback: Remove !SPLIT_DEVICES code path
778aa6da1fd9 media: v4l2-loopback: Allocate the device number dynamically
8bc12e106311 media: v4l2-loopback: Do not any create devices in *init_module()
073bd4bf72f7 media: v4l2-loopback: Import the driver

By continuing this trend I'll have a driver in few weeks :-)

#linux #kernel #video4linux

@Conan_Kudo @wtay I aim to send RFC next month....

@Conan_Kudo @wtay https://github.com/umlaeute/v4l2loopback/issues/268#issuecomment-2495881766

@Conan_Kudo @wtay So the other problem is racy /dev/videoX instance. The problem is in that state changes of the video device are racy by definition. That is obviously unacceptable.

I.e. probably APi should be something along lines of:

1. fd = open("/dev/video_loop")
2. ioctl(fd, "set properties")
2. ioctl(fd, "create")

And post that anything that the device is written goes through that fd and is tied to its life-cycle. That is the only way to guarantee that it is tied to life-cycle of the device per se. Only when the fd is written nothing ever happens in the state of /dev/videoX.

For testing a tool is needed for "capture devices", which will create something for ffmepg to write to so that another ffmpeg instance can play it from /dev/videoX.

@Conan_Kudo @wtay

OK, so I think what goes wrong in high-level in the OOT driver and its uapi goes in core essence into: if you provide a service, you DO NOT use the client API to implement your service. Just basic API bullshit, overall, not like in kernel particular...

So instead when you open an fd then "you are /dev/videoX" or whatever. I.e. write ops go to the fd not any of /dev/videoX.

So... based on these it's a fuse alike driver for webcams. There really should maybe one /dev/video_loop device or whatever is a good name , and when you open that file, the creation of that file implies the creation of /dev/videoX.

After that the fd interface in user space gives all data and meta-data that you could expect similar devices.

So I think this is the gist of getting it wrong in uapi in that driver. But yeah like internals and thinking went on those can be quite easlily refactored out and wrapped in a nicer API package.

So yeah I'll do what I do put this in clean shape and send RFC patch set. So can CC obviously people to that once I get it out (few weeks smthng).

I have a dev-tree: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=v4l2-loopback-dev

1. Suck inner guts out of the OOT driver.
2. Wrap it up tpm_vtpm_proxy

So generally looking for advice on:

1. #Pipewire interaction
2. #Gstreamer interaction

Focus on what instead of how. I.e. if this existed how would uapi play for those upstream projects?

#linux #kernel #video4linux #webcam

@timojyrinki @mmin @Jesse bitwig

small extra trouble which would widen embedded coverage so much more. just don't get it tbh. data center infrastructure mob is dominating the linux upstream i guess ;-)

@pavel @vbabka i've tried to give feedback in some reviews to make sure that test script would be busybox ash (i.e. #!/usr/bin/env sh) compatible but some others have downplayed that feedback ;-) at least i've tried...

especially with preproduction hardware it is not uncommon start with fpga so it would somewhat feasible to reduce image size for kernel + kselftest... because loading is SLOW