- From: Michael Schöffler <michael.schoeffler@audiolabs-erlangen.de>
- Date: Tue, 14 Feb 2012 12:11:47 +0100
- To: <public-audio@w3.org>
- Message-ID: <002301cceb09$71360360$53a20a20$@audiolabs-erlangen.de>
I don’t want to set to focus of the “Standardizing audio "level 1" features first?” issue on channel handling, so I decided to start a new thread. Here are some other issues, that I have noticed during development. Maybe they’re helpful. - Six channel limitation of Splitter/Merger Currently every splitter or merger is limited to 6 channels. If you have to merge/split lots of channels (e.g. 40), you need more than one merger/splitters to handle it. This is not a big thing, because it is only a limitation by a constant in the source code. But maybe it would be a good thing to set the number of split/merged channels by the API. My suggestion is to add a new parameter to context.createChannelSplitter(). An alternative would be to increase the value of the constant (e.g. to 1024). But I think the numberOfInputs-attribute of a merger shouldn’t have a value of 1024. Also it could be possible that the developer wants to check of the number inputs the merger is capable. - Upmixing even if a merger is used Yesterday I set up two configurations ( <http://h9.abload.de/img/updownmix6exmy.png> http://h9.abload.de/img/updownmix6exmy.png <= I hope this scheme explains it well). If an merger is used, there is anyway an upmixing (mono to stereo). I was able to follow the WebCore source code and I had no problems to understand it. But I just want to say that I expected another behavior. As workaround I used an AudioNode that writes a mute signal to the buffer. For me it feels sometimes, that handling with channels (in the way I do) means also handling with a lot of workarounds. Therefore I would be interested in other opinions/experiences about the channel handling J Btw. Chris this about WebCL didn't sound as negative to me, I’m just very interested in other opinions. Thank you for yours!
Received on Tuesday, 14 February 2012 11:12:37 UTC