Closed Bug 1439407 Opened 2 years ago Closed 2 years ago

CHANNEL_ORDER_TO_INDEX and CHANNEL_INDEX_TO_ORDER waste a lot of space

Categories

(Core :: Audio/Video: cubeb, enhancement, P3)

enhancement

Tracking

()

RESOLVED DUPLICATE of bug 1432779
Tracking Status
firefox60 --- affected

People

(Reporter: froydnj, Unassigned)

References

Details

CHANNEL_ORDER_TO_INDEX looks like:

static int const CHANNEL_ORDER_TO_INDEX[CUBEB_LAYOUT_MAX][CHANNEL_MAX] = {
//  M | L | R | C | LS | RS | RLS | RC | RRS | LFE
  { -1, -1, -1, -1,  -1,  -1,   -1,  -1,   -1,  -1 }, // UNDEFINED
  { -1,  0,  1, -1,  -1,  -1,   -1,  -1,   -1,  -1 }, // DUAL_MONO
  { -1,  0,  1, -1,  -1,  -1,   -1,  -1,   -1,   2 }, // DUAL_MONO_LFE
  {  0, -1, -1, -1,  -1,  -1,   -1,  -1,   -1,  -1 }, // MONO
  {  0, -1, -1, -1,  -1,  -1,   -1,  -1,   -1,   1 }, // MONO_LFE
  { -1,  0,  1, -1,  -1,  -1,   -1,  -1,   -1,  -1 }, // STEREO
  { -1,  0,  1, -1,  -1,  -1,   -1,  -1,   -1,   2 }, // STEREO_LFE
  { -1,  0,  1,  2,  -1,  -1,   -1,  -1,   -1,  -1 }, // 3F
  { -1,  0,  1,  2,  -1,  -1,   -1,  -1,   -1,   3 }, // 3F_LFE
  { -1,  0,  1, -1,  -1,  -1,   -1,   2,   -1,  -1 }, // 2F1
  { -1,  0,  1, -1,  -1,  -1,   -1,   3,   -1,   2 }, // 2F1_LFE
  { -1,  0,  1,  2,  -1,  -1,   -1,   3,   -1,  -1 }, // 3F1
  { -1,  0,  1,  2,  -1,  -1,   -1,   4,   -1,   3 }, // 3F1_LFE
  { -1,  0,  1, -1,   2,   3,   -1,  -1,   -1,  -1 }, // 2F2
  { -1,  0,  1, -1,   3,   4,   -1,  -1,   -1,   2 }, // 2F2_LFE
  { -1,  0,  1,  2,   3,   4,   -1,  -1,   -1,  -1 }, // 3F2
  { -1,  0,  1,  2,   4,   5,   -1,  -1,   -1,   3 }, // 3F2_LFE
  { -1,  0,  1,  2,   5,   6,   -1,   4,   -1,   3 }, // 3F3R_LFE
  { -1,  0,  1,  2,   6,   7,    4,  -1,    5,   3 }, // 3F4_LFE
};

Note that for each subarray, we're only defining 10 entries or so, but CHANNEL_MAX is 256, so we're leaving 95% of the subarray initialized to zeros that will never be read.

CHANNEL_ORDER_TO_INDEX is 19,456 bytes on x86-64 Linux; the above table suggests it should be 1k or less.  That's a fair amount of wasted space.  Even just shrinking the entries to int8_t would be a big win.

CHANNEL_INDEX_TO_ORDER is similar, but with even fewer initialized entries in its subarrays, which means even more wasted space.
Is this something you could look at Alex?
Blocks: 1331869
Rank: 22
Flags: needinfo?(achronop)
Priority: -- → P3
I would suggest to limit the CHANNEL_MAX the max available. In our case this is 12. Matthew do you see any problem with that?
Flags: needinfo?(achronop) → needinfo?(kinetik)
No, I'd be happy with that.  I have more of a problem with it being changed to 256 in the first place... that happened in https://github.com/kinetiknz/cubeb/pull/288, so unless Paul has an argument for it being so large, let's reduce it.

Changing the type of the entries to int_8 is also a good idea.
Flags: needinfo?(kinetik)
Let's do both.
All this code has been removed in bug 1432779
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1432779
There's also no more a concept of max audio channels, the limit is whatever the backend support and with 32 being a soft limit (meaning any amount of channels beyond that and it will typically play rubbish)
You need to log in before you can comment on or make changes to this bug.