add conv4_stride to VGG4LayerActFrontendV1

[michelwi]

As discussed in #17 (comment) we wanted to add stride parameter to (at least) the conv4 layer.

Do we want strides at the other layers, too?

[christophmluscher]

This module does the striding via the pooling layers, not the convolutional layers.

We would need to discuss if this is a new module or the same... I find that there are already a lot of parameters here...

[michelwi]

We would need to discuss if this is a new module or the same.

I had the impression it was intended to add down sampling also via conv layers..

I find that there are already a lot of parameters here...

that's an argument that we might as well add another one xP

[SimBe195]

Imo pooling strides and conv strides are not really an "either-or" case, sometimes you might want to have both, e.g. conv strides over time-axis and pooling over feature-axis. So I would not create a new module for this. But for consistency I would add the config parameter for all of the conv layers, not just conv4.

[albertz]

Just as a reference, the implementation we have in RETURNN frontend (earlier RETURNN-common) (originally via @mmz33):
https://github.com/rwth-i6/returnn/blob/a8ffd0b734e0d7fc03a92575019253a31b50075a/returnn/frontend/encoder/conformer.py#L82

This can handle most of our older TF-based setups as well as ESPnet setups.

The strides of convolutions are configurable, and the strides of the poolings are just the same as the pool size (which are configurable) (which is the common case of pooling).

[christophmluscher]

that's an argument that we might as well add another one xP

true

I had the impression it was intended to add down sampling also via conv layers..

I don't remember, but I am also fine with both

But for consistency I would add the config parameter for all of the conv layers, not just conv4.

I think this is a good point.

[christophmluscher]

more generic and flexible frontend in PR #39