The 32 channel limit excludes use of audio interfaces like for example (my) RME HDSPe MADI (64x64), all other MADI interfaces (incl. RME MADIface), RME Fireface UFX+ (94x94), MOTU 1248 (32x34), MOTU 112D (112), Focusrite Red (64x64), ProTools hardward, and more. In general, we're excluding many pro audio and prosumer audio interfaces. A workaround could be to limit use of first 32 channels instead of crashing with assert on startup. Happy to work on a patch if you see this as a potential path. *KLAUS BADELT*Founder kinonation.com <http://klausbadelt.com/> @Kinonation1 On Mon, Jan 23, 2017 at 11:57 PM, Tanu Kaskinen <tanuk at iki.fi> wrote: > On Tue, 2017-01-17 at 19:53 -0800, Klaus Badelt wrote: > > --- > > src/pulse/sample.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/pulse/sample.h b/src/pulse/sample.h > > index 4299eec..613c3e8 100644 > > --- a/src/pulse/sample.h > > +++ b/src/pulse/sample.h > > @@ -125,7 +125,7 @@ PA_C_DECL_BEGIN > > #endif > > > > /** Maximum number of allowed channels */ > > -#define PA_CHANNELS_MAX 32U > > +#define PA_CHANNELS_MAX 64U > > Unfortunately, we can't change the PA_CHANNEL_MAX value. It affects the > size of the pa_channel_map and pa_cvolume structs, and applications > break if the size of those structs changes. If 32 channels is not > enough, some other approach is needed. Without knowing the details of > your problem I'm not able to suggest anything. Adding new APIs that > support 64 channels would be one possibility, but that would require > quite a lot of work. > > -- > Tanu > > https://www.patreon.com/tanuk > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20170124/4cde0b80/attachment.html>
