Re: [ecasound] Propagation of signal width with jack inputs

Hi,

On Sat, 6 Nov 2010, Joel Roth wrote:

> -a:3 -f:f32_le,1,44100 -i:jack,,brass_in
> -a:3 -chcopy:1,2
> -a:1 -o:jack_multi,system:playback_1,system:playback_2
[...]
> Due to the -chcopy operator on chain 3, I expect the output
> to be stereo, but jack_lsp -c and ecasound debugging output
> show the output to be mono.

yup, this is actually a feature not a bug. So when you add '-chcopy:1,2',
the chain '3' automatically become stereo.

But this does not automatically make the outputs connected to that chain
to have at least two channels (remember there could be multiple chains
connected, and some may have 1 channel while some might have many more).

Arguably ecasound could add special-case handling for the case where
exactly one output is connected, or at least warn about this at
'cs-connnect' time ("hey, some of the channels of chain '3' are going to
bit heaven").

But currently, '-f:f32_le,1,44100' sets the format for all subsequent
audio files, until a new '-f' is given.

> Output (1): "jack_multi,system:playback_1,system:playback_2" - [JACK interface]
> -> connected to chains "1": realtime-device; position 0, delay 0.
> -> open, f32_le/1ch/44100Hz, buffer 1024.
> ^^^^^^^^^^^^^^^^

So following from the above, this is as expected, but probably something
ecasound should warn about.

> The correct stereo output _does_ appear when
> the input line changes to:
>
> -a:3 -f:f32_le,1,44100 -i:jack,system:capture_1

Hmm, assuming that's really 1 as the channel count (not a typo), that's
indeed puzzling.

> Output (2): "loop,Master_in" - [Internal loop device]
> -> connected to chains "3": position (0.000/0.000) seconds.
> -> open, , s16_le/2ch/44100Hz, buffer 0.
>
> And now I'm surprised that the signal formats
> are s16_le! I thought 32-bit signals were always used
> internally. Could 16-bit format be being inherited

Yes, that's actually another thing and a bug (and just fixed in git
master). The sample type is basicly irrelevant for loop object, as loop
objects always use the same sample type as the engine (i.e. always f32
currently). So 's16_le' here is just misinformation.

> Also Input (2) shows a stereo signal, despite the chain
> setup input line specifying mono. Is that due to the -chcopy
> operator?

I think that's related to something fishy between requesting a certain
channel count for 'jack_multi' objects, and how many destinations you pass
to 'jack_multi'. Basicly ecasound could count the parameters from
'jack_multi,a,b,c' params and lock the channel count of the object based
on that (i.e. 'a,b,c' -> fixed to 3 channels).

However current ecasound code assume the two values are in sync. E.g. if
you have "-f:,2," ecasound expects "-o jack_multi,x,y" and nothing else.
This is something that I need to investigate further. My immediate
reaction is that 'jack_multi' should fix the channel count based on the
params (so if you pass four ports, the channel count visible to other
ecasound objects should be fixed to four as well, and so forth).

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Mon Dec 13 04:15:05 2010