headers
Julien Claassen | 12 Dec 2010 17:18
Picon

Constantly visible JACK ports

Hello all!
   We've been wondering over at the Nama mailing list again, if it might not be 
possible to somehow keep JACK ports running as long as possible. I wondered, 
as a first step in that direction, might it not be possible to have an 
ai-replace and ao-replace command?
   So I could do:
ai-select jack_alsa
ai-replace /home/songs/long/nama/project/.wav/track_1.wav
   So at least the output of that chain (probably ecasound:out_1 and 2, 
connected to system:playback_1 and 2 can persist, as well as all the other 
ports of the chainsetup.
   I don't know, what exactly is done, when I remove an input, but I 
immediately get an error, telling me that the current chainsetup can't be 
connected. For an ai-replace command that step might be skipped in between. So 
it would perform most of:
ai-remove [but not check]
ai-add new-input
[and then check]
   Or does the engine have to be stopped completely to change anything in the 
chainsetup?
   Wat might be other ways to help in this respect? Perhaps allow creation of 
jack porrts (ask for 12 out and 6 ins) and assign them to chains, when needed. 
would that work? If the ports aren't used, just feed them with null audio or 
lose their audio data in the nirvana of computers? I seem to remember, that 
JACK ports have to have a valid process function, if they should be connected 
to something.
   So in my setup, I can temporarily skip a recording chain, leave its port 
with its connections running and listen to some recorded material, on a 
different chain. then switch back. I guess this is a mute/don't process 
feature.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kai Vehmanen | 12 Dec 2010 18:33

Re: lossless conversion broken?

Hi all,

finally some news about this:

On Wed, 3 Nov 2010, Dan Muresan wrote:
>> So this is basicly the "asymmetric" method in:
>> http://blog.bjornroche.com/2009/12/linearity-and-dynamic-range-in-int.html
>
> I agree with the jackit threads -- introducing a nonlinear
> transformation in a chain is not a good thing (from a signals &
> systems POV). Sounds like 0x8000, symmetrical would be best for the
> future. I assume this breaks existing files, which is why you'd have
> to wait for a major release.

This turned out to be fairly complicated thing to fix/implement, even 
after taking another close look at how other projects are handling this.

The 0x8000/2^N conversion seems to be the right thing to do. In practise 
it causes tricky complications to the float-to-fixed case. When fed 0dBFS
signals generated in floating point domain (e.g. a full scale sine coming 
from another JACK client), scaling with 0x8000 would cause an overflow
(1.0 x 0x8000 -> 32768.0f which doesn't fit a int16_t value).

So what to do? We can't tell JACK clients to use a different 0dbFS point. 
This is the reason why libsndfile has different scaling for int-to-float 
and float-to-int (which again cause bit errors for fixed-float-fixed 
conversion). See:
       http://www.mega-nerd.com/libsndfile/FAQ.html#Q010
.. for the rationale.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kai Vehmanen | 12 Dec 2010 19:04

Re: lossless conversion broken?

Hi,

On Fri, 5 Nov 2010, Dan Muresan wrote:

> I'm curious, what are the consistency requirements for a minor vs.
> major release? I've just realized that there is no custom Ecasound

basicly the versioning policy is documented in the beginning of NEWS:

--cut--
About the version numbers... "vX.Y[.Z[.R]][+extraT]" :
------------------------------------------------------

   X = major version  - incremented after major redesigns
   Y = minor version  - incremented when new features are added
   Z = micro version  - incremented if major.minor version is not
                        modified (optional)
   R = revision       - urgent fixes to planned releases (optional)

   extraT             - 'beta', 'pre' and 'rc' releases (optional)
--cut--

So a fairly loose set of criteria. In practise, change in X.Y is a signal 
that users should pay more attention when upgrading (check what new 
features are available, do a basic smoke test with old features they use 
the most). I think this conversion change is X.Y material, as it has an 
impact (albeit very small) to all use-cases.

> file format (i.e. floats never get stored in any files). What would be
> affected by changes in the conversion formulas?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Vehmanen | 12 Dec 2010 23:04

Re: Ecasound-JACK buffer size mismatch

Hi,

On Sat, 6 Nov 2010, Joel Roth wrote:

> I've been getting this message at random when
> connecting a chain setup:
>
> Connecting chainsetup failed:
> "Enabling chainsetup: AUDIOIO-JACK: Cannot connect open connection!
> Buffersize 128 differs from JACK server's buffersize of 1024."

normally ecasound checks jackd buffersize whenever you "cs-connect", and 
sets the chainsetup buffersize to match that of JACK.

In in your case:

> (eca-session) Connecting chainsetup
> jack_client_new: deprecated
> (eca-chainsetup) jackd buffersize check returned 1024.
> (eca-chainsetup) overriding buffersize.

This actually looks correct. The above "overriding" means that the value 
will override whatever settings that are coming from buffering mode 
profile. I.e...

> (eca-chainsetup) bmode-selection case-1
> (eca-chainsetup) "rt" buffering mode selected.
[...]
> buffersize: 128
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Vehmanen | 13 Dec 2010 00:09

Re: 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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kai Vehmanen | 13 Dec 2010 00:23

Re: Constantly visible JACK ports

Hi,

On Sun, 12 Dec 2010, Julien Claassen wrote:

>   We've been wondering over at the Nama mailing list again, if it might not be
> possible to somehow keep JACK ports running as long as possible. I wondered,
> as a first step in that direction, might it not be possible to have an
> ai-replace and ao-replace command?

this would be highly desirable, but currently not possible, and quite 
difficult to implement. Current ecasound codebase is just not prepared to 
cope with modifying the static configuration (adding/removing audio 
objects, chains, chainops) while chainsetup is connected (~= engine 
running).

>   I don't know, what exactly is done, when I remove an input, but I
> immediately get an error, telling me that the current chainsetup can't be
> connected. For an ai-replace command that step might be skipped in between.

When you perform an operation that cannot be done while chainsetup is 
connected ("Real-time commands" listed in ecasound-iam(1)), ecasound 
disconnects the chainsetup automatically, performs the operation and tries 
to reconnect.

This works in some cases (like adding a new chain operator with 
'cop-add'), but if you remove an input, then the reconnect will fail (as 
some chain will not have any input).

So to implement this better, the client should explicitly disconnect the 
chainsetup, perform a set of ops that result in a modified chainsetup that
(Continue reading)

Permalink | Reply | 2 comments |
headers
Julien Claassen | 13 Dec 2010 01:38
Picon

Re: Constantly visible JACK ports

Hello Kai1
   Thanks for the quick response. so there is - at the moment - no short and 
easy or dirty way to acheive something like it?
   Would you be willing to work on something to allow for permanent connections 
in the future, when time and motivation allow for it? What we be the chance of 
motivation for that? :-)
   Warmly yours
             Julien

--------
Music was my first love and it will be my last (John Miles)

======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Permalink | Reply | 1 comment |
headers
Kai Vehmanen | 13 Dec 2010 22:04

Re: Propagation of signal width with jack inputs

Hi,

On Mon, 13 Dec 2010, Kai Vehmanen wrote:

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

ok, this is now fixed in git master as well. So if you do:

ecasound -i null -f:32,1,48000 -o jack_multi,foo:in_1,foo:in_2

If with 2.7.2, jack_multi would end up mono (as requested by the user), 
and foo:in_2 connection would not be made.

With current git, jack_multi object will be listed as stereo (so the 
parameter list passed to jack_multi overrides the channel counter 
request), and connection to 'foo:in_2' is made.

I think this is the right thing to do.

Thanks for the bug report!

------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kai Vehmanen | 13 Dec 2010 22:33

Re: Constantly visible JACK ports

Hi,

On Mon, 13 Dec 2010, Julien Claassen wrote:

>   Thanks for the quick response. so there is - at the moment - no short and
> easy or dirty way to acheive something like it?

no, I'm afraid not. This is one shortcoming, for which there aren't even 
dirty workarounds available.

>   Would you be willing to work on something to allow for permanent connections
> in the future, when time and motivation allow for it? What we be the chance of
> motivation for that? :-)

To be honest, it is very unlikely I will have time for this (unless 
there's a major disruption with other projects I'm involved with).

Problem is that this goes to fundamental design choises, as is something 
much easier to solve when developing from scratch, rather than 
retrofitting to an old design. So in short, it's a huge amount of work 
(and most likely something that will grow bigger and bigger as go 
forward).

The core issue is that once the session data (a chainsetup) is passed to 
ecasound's engine, the engine owns the whole data structure and offers 
only a very limited interface to modify it during runtime (i.e. operations 
that are fully real-time safe and deterministic). For any edits requiring 
actions that are not real-time safe (e.g. allocating memory), the session 
must be passed back to the non-real-time frontend. Replacing an object is 
still easy, but reinitializing dependent parts of the engine can be really
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Vehmanen | 13 Dec 2010 22:39

Re: cs-set-length has no effect when a live input is present

Hi,

On Thu, 7 Oct 2010, Joel Roth wrote:

> If this behavior is known and an accepted limitation, I
> think it should be documented.

let's see:

> ecasound -a 1 -i aco_67.wav -o alsa,default \
>         -a 2 -i alsa,default -o test.wav \
>         -c
[...]
> ecasound ('h' for help)> cs-set-length -1

I think you've just hit one special-case. Quoting ecasound-iam(1) man 
page:
--cut--
dit(cs-set-length 'seconds')
Sets processing time in seconds (doesn't have to be an integer value).
A special-case value of '-1' will set the chainsetup length
according to the longest input object. em([-])
--cut--

I just tried and if you set e.g. "cs-set-length 10", this will work 
correct even with chains that have infinite inputs/chains (never finish
to an end-of-stream condition).

Or did I miss something?
(Continue reading)

Permalink | Reply | 2 comments |

Gmane