Justin > I'm not sure I would use a module to do this. It seems like you could make > your bluetooth stack a pulse client instead. We have a variety of software > systems that might want access to the pulse output, so I created a "system" > sink that is just a null sink. If they want access to it, they can just > attach to the "system" monitor source. I have yet to see how well that > actually works in practice, but it means I don't have to worry about all > those user-level stacks. we have potential problems with latency so I think I'd want to avoid a separate process that has the audio passing through it. > However, if you did want to make a module, alsa might not be the right model > to follow either. The ALSA interface is pretty specific to ALSA, so its a > bit confusing. The OSS module is a good reference for a char style > interface, but it sounds like you have a plan to use pipes, so why not just > alter the module-pipe to meet your needs? If there was a network module I would start there--sound devices come and go, transport is lossy, latency can be problematic, etc. But it isn't written as a module I guess. Maybe bluetooth would be a module that provides a protocol like pulsecore/protocol-http.c? I don't know the terminology or architecture that well and the docs I did find on extending pulse basically said to look at the source. Brad
