[Tfug] Audio client

[Bexley Hall]

Hi Harry,

> > I.e., consider speakers from a small "integrated" bookshelf
> > stereo that are currently tethered to that stereo with cables.
> > Get rid of the stereo.  Put the speakers where you want them.
> > Then just plug them into a CAT5 PoE drop (i.e., the CAT5
> > cable takes the place -- cosmetically -- of the "speaker cable")
>   
> Either would work, I would end up putting a "wall jack" at the end of
> the cat-5, and then a patch cable (1 foot) between it and the device.

Yes.  I've located the CAT5 drops here with this sort of thing
in mind.  Though that may just be a natural consequence of
drops wanting to be "in corners" -- which is where speakers
*also* tend to be located!  :>

> >> onto solid, even with solid rated (smokey) RJ45 plugs, it's just 
> >> never as reliable as 110 punch downs.
> >
> > Hmmm... I will have to look into that.  Moving power over the 
> > connector makes this a bit more critical.
> >
> > Though, as I read my arguments, here (and yours), it occurs to
> > me that I should also consider a USB host port implementation.
> > And, a connector for an external power supply. The MCU's I
> > have been looking at have lots of I/O that I am not using
> > (including USB).  The USB connector could be colocated with
> > the RJ45 (i.e., populate the board with one or the other).
> > It's purpose would be to allow you to plug in a wireless
> > USB dongle!  I.e., wired network gets replaced with *wireless*.
> > Then, you no longer have PoE available so you need an external
> > power supply (wall wart/brick) to power everything.
>
> I would not do either/or, I would put on a Mini-B connector, they are

<frown>  It seems like you always need a cable or adapter to
mate to these.  Also, the B connector, IIRC, goes on the
*peripheral*, not the host (or do I have this backwards?).
I.e., I want the sort of connector that is on a *PC*, not
on a printer.  (so, you should be able to plug a thumb drive
into this box -- not that you would *want* to)

> quite small, or the newer Micro-B connector (some cell
> phones are starting to use it now.
> 
> http://en.wikipedia.org/wiki/File:Types-usb_new.svg
>
> > This gives you a whole different way of using the device
> > (wireless stereo/speakers)
>
> Depending on the intelligence of the board, you could even
> make it use a USB wireless stick, but that may way too much creep.

That';s what I meant:  a wireless dongle.  (i.e., the size of a
thumb drive but contains a 802.11a/b/g/n transceiver -- wide,
flat USB connector suitable for plugging directly into a PC)

The hardware is there -- I just wasn;t planning on using
it originally (as I couldn't envision a use for USB on a
"speaker")

> > Yes.  My original idea was to do exactly this (AIFF, etc.).
> > But, the processors that are available with the right
> > bits of onboard I/O have *way* too much horsepower.  So,
> > I can "waste" some of that on a codec.  I am also thinking
> > that some small amount of signal conditioning could be done
> > in the processor (e.g., tone controls, programmable delay,
> > etc.).
> >
> > The point is *not* to try to support all these silly formats
> > that keep coming up.  Pick one (or *make* one) and then push
> > all of the conversion into the host/server.  Folks like me
> > can just one-time convert their entire music library.  Folks
> > who want to stream audio from internet sources would need a
> > transcoder,e tc.
>
> Ogg Vorbis would probably be a good idea then, but I would also keep
> AIFF support, too many people hate compressed codecs.

But, for those folks, you could hide that detail in your
"virtual soundcard" idea.

> >> If you put it behind the virtual sound card, then you only
> >> have to worry about one codec, and you can use a patent safe 
> >> codec such as Ogg Vorbis.
> >
> > Exactly.  I don't want to commercialize this.  I'd rather just
> > order a bunch of extra boards and let folks assemble their own
> > and take it whichever direction they want.  OTOH, if you just
> > give people a board and a schematic, few folks have the capability
> > to "build from scratch" a real system.
> 
> Ability or time.

Yes.  As you get older, time becomes the all important issue!  :>

> If it's basic, even surface mount soldering, I would
> be ok, but I just don't have the time for that sort of
> project right now (2 and a half year old, and a 3 week 
> old at home,

Ah, see, you forgot the Magic Words:  "Not tonight, Honey -- I've
got a headache!"  :>

> plus teaching, plus a full time job.

> >>>> Sounds very cool, we did a bunch of work with the Channel
> >>>> Vision's A-Bus products.
> >>>>
> >>>> Worked quite well, but very expensive.
> >
> > I couldn't find the modules you were talking about at the URL.
> > There were some "big boxes" that seemed to do stuff like that
> > but I was assuming you were talking about something *small*
> > (i.e., fits in a 1G JBOX)
>   
> It's the "front end" that fits in the wall plate, the back
> end is the bigger device.

Ah, OK.  So what I am looking to do would be to combine both
(for low power applications) into "the smaller".

> http://www.smarthomeusa.com/ShopByManufacturer/Channel-Vision/Item/AB-124/

> >> The low power amp was fed power over the CAT-5 (non ethernet, just
> >> cat-5), and so all you have is the speaker (left and right) and the
> >> Cat-5 connection.
> >
> > Ah, OK.
>
> http://www.smarthomeusa.com/Products/AB-124/manuals/AB-124-ins.pdf

Thanks!
 
> > Yes.  There are other extensions as well.  E.g., you could apply
> > this in a VERY LARGE (outdoor) setting (esp. if you do the
> > wireless trick) and deploy each box at varying distances from
> > the stage.  You then deliberately introduce a delay in the
> > signal path that is proportional to distance from stage / speed 
> > of sound so that the sound emitted from "this" speaker is
> > coincident with the acoustic wave arriving from the speaker(s)
> > closer to the stage.
>
> If you could combine this with a mike on a laptop to tweak
> it for you that would be a sweet hack.

*Someone* could do it.  But, I am not interested.  :>  I was merely
offering it up as an idea of how you could morph this into other
uses.

> You walk around, it based on the tones coming out of the diff speakers,
> it tweaks the delay of the speakers based on your position, you move,
> and it tweaks it further.

Yes.  What you would do is generate a tone burst with a controlled
envelope.  (i.e., amplitude modulated -- though the same could
be applied to FM).  Then, "listen" to the tone and track the
shape of the envelope in order to find a "reference spot" on the
signal.  Then, compute the time difference.

A gross approach would be to just take the output of the
"unit to be delayed", invert it and sum it with the signal
from a microphone.  Then have the software twiddle the
delay and internal gain until it found a null.

> > (I've been to concerts where this was done with wired audio
> > distribution and programmable delay lines)
> >
> > However, you have to be able to synchronize the audio streams
> > between each of these nodes and fully characterize the performance
> > of your network stack.  This is a problem that doesn't exist when
> > you process all of the audio in *one* box.
>
> Ethernet and not wireless would be best for this, in a
> switched environment, you won't have much variability.

<frown>  That depends.  If all of the nodes on the switch are 
seeing the same sort of traffic (rates), then entropy is
your friend.

OTOH, if one node sees lots of traffic and packets are queued
up, then the delay through that switch port differs from the
delay at another port (without queued packets).  It's what,
120us per packet?

If I chose to implement this using a broadcast technology,
then this wouldn't be as problematic.  The data for *every*
client would appear on the wire at (roughly) the same time.
(i.e., let each client filter out that portion of each
packet that it is interested in -- e.g., "Left Front" vs.
"center", etc.)

But, if I push packets to individual clients (i.e., "here is
the next 500 samples of audio for you to 'play'"), then the
data for each client appears skewed in time from the other
clients.  I.e., the sample for t=t0 is sent to client A
perhaps a millisecond before/after the sample for t=t0
is sent to client B.  (i.e., the clients need to deliberately
delay their rendering of the data samples until the right
instant in time -- otherwise you gt phase errors in the
reproduction).  For a 7.1 system, that can be almost a ms
between the first and last client (?)

> >> That would be very nifty.
> >>
> >> I would use a jumper or dip switch on the device to select
> >> single or dual channel operation.  The device would report what
> >> it was capable of to the driver over the TCP/IP connection.
> >
> > Hmmm... I would have to think on this.  I dislike jumpers as
> > they are things that people can screw up.  I will have to look
> > at the audio amp selections and see if I can garner any information
> > from the amplifier "at run time" that lets me determine what
> > sort of a load I have.
> 
> If you can figure it out in software, that would be cool, as long as the
> default is dual channel, I don't see many people getting confused by a
> jumper.

I'd rather just sense the load and *know* what I (meaning "the client")
has to do rather than forcing the user to strap the board appropriately.
I may opt to have the use wire mono apps using the "stereo" amplifier
in a bridged configuration (for more power) so this acts AS IF it
was a jumper (if youhave two speakers attached then you are a stereo
device; if one, then mono)

> > That was one of the initial motivators I had for this.  But, our
> > ceilings here would cook speakers (flat roof so ceiling == roof).
> > Screwwy way to build things!  :<
>   
> Yep, my last install of these had a much larger ceiling space (but no
> attic).

<frown>  Attics and basements.  I never considered them luxuries before
but I sure do NOW!
 
> Unfortunately most of my walls at home are either brick, or
> 1" deep wood on brick.

Understood.  The exterior walls of the house are firred out
on 1" strips so totally impractical for this.  The ceiling would
be ideal -- since you have more leeway in where you can move
the sound source -- but the temperature up there *has* to be
lethal for speaker cones.  :<