- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Wed, 29 Jan 2014 19:04:10 +0000
- To: Emil Ivov <emcho@jitsi.org>
- CC: Justin Uberti <juberti@google.com>, Roman Shpount <rshpount@turbobridge.com>, Peter Thatcher <pthatcher@google.com>, "public-orca@w3.org" <public-orca@w3.org>
Emil said: > #1 is about timely dominant speaker identification, presumably without false speaker switches. > > To do this well, you may need to do more than firing an event based on changes in a ranked list of speakers based on averaged levels; better approaches tend to actually process the audio. > > For example, see > http://webee.technion.ac.il/Sites/People/IsraelCohen/Publications/CSL_2012_Volfin.pdf [Emil] Right. That's why per-packet hdr extensions carrying the CSRC levels would be the best (and only in the case of mixed streams) way to implement any of the above. So, if we could have events triggered for every new level, then we should be good. Unless I am missing something, this should be covered by Peter's suggested API. [BA Rather than providing access to per-packet hdr extensions or triggering an event for each new level (which could end up resulting in an event in a large fraction of packets) could the Web audio specification be used? https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html In particular, I am thinking about the ScriptProcessorNode Interface (Section 4.12).
Received on Wednesday, 29 January 2014 19:04:58 UTC