[Ksummit-discuss] Draft agenda for the kernel summit

Takashi Iwai tiwai at suse.de
Tue Oct 20 15:47:24 UTC 2015


On Tue, 20 Oct 2015 17:18:16 +0200,
Mauro Carvalho Chehab wrote:
> > Looks nice. Fwiw, the graph will probably get a lot bigger when we show
> > the audio DSP and codec paths (as DSPs and codecs have multiple muxes
> > and mixers).
> 
> Yeah, the graph is simplified, as for now we only needed to represent
> the parts of the graph that are associated with the ALSA interfaces.

So this doesn't expose the graphs inside USB-audio chip but rather
only the mixer elements parsed by ALSA driver, right?  That's what I
understood from Shuah's patchset, so far.

> > It may be good to have a cmd line option to stop at certain
> > nodes on the graph to avoid over populated/complex graphs ?
> 
> Yes, it makes sense to have some ways to simplify the graph plot.
> Yet, I'm not sure yet what would be the best ways to simplify
> the graph when plotted, as this is not a simple task.
> 
> For example, on the au0828/snd-usb-audio graph, the dvb-demux entity 
> actually has a lot more than 5 source PADs. The demux basically gets
> a MPEG-TS stream and splits audio, video and data channels on different
> I/O outputs. Most drivers (including au0828) have 256 outputs.
> Each node connected to two or more I/O entities. On an USB driver
> like this one, those outputs are seen via two device nodes, but
> TV sets and Set Top Boxes provide ways to wire the output of the
> demux to the aSoC and to the DRM driver, in order to be able to
> output sound and video directly. On some hardware, it is even possible
> to reboot the CPU keeping those wires while the CPU reboots. So, the
> user may not even notice if the CPU reboots due to some trouble.
> 
> So, we need all outputs of the demux to be controlled by the Media
> Controller, for it to allow dynamically route audio and video to
> the right entities at the ALSA and DRM parts of the graph.
> 
> The au0828 graphs that Shuah and I have were generated with a Kernel
> hack patch that reduces the number of outputs to just 5, just to make
> the graph visually readable. Of course, such patch should not be sent
> upstream, and we need to find a solution on userspace to simplify
> the graph on plots.
> 
> There are some ways that we could do that:
> 
> 1) we could group entities/interfaces per subsystem. So, if all the user
> wants is to see ALSA-related nodes, it will filter out the other nodes
> (eventually, keeping the nodes that are directly connected to ALSA
> but belongs to the other subsystems);

This actually made me wonder how all things are managed.  Are all
mapped into the same topology, or they are individual trees (e.g. per
device object)?


thanks,

Takashi


More information about the Ksummit-discuss mailing list