Ask a question - edaboard.com
elektroda.net NewsGroups Forum Index - Electronics Design - "Efficient" audio amp selection
Don Y
Guest
Guest
Sun Jan 15, 2012 11:30 pm
Hi Joseph,
On 1/13/2012 11:04 PM, josephkk wrote:
Quote:
So far, my searches keep bringing me to TI's class D offerings -- though
none seems to be the perfect cherry. And, class D leaves me worrying
about sound quality and RFI (generated) -- esp when the loads aren't
close to the amp (e.g., the two channel case)
Pointers?
Put some high-frequency filtering at the output of the amplifier.
I'm concerned with the *bulk* that would involve (note the entire
device wants to be just a couple of cubic inches). It's alarming
how quickly that volume gets eaten up (electronics, connectors, etc.)
My original vision was for a single channel device bolted directly
to the driver. I.e., it's bulk hides in the speaker's envelope;
no long wires leading *to* the voice coil from the device, etc.
I.e., the two channel optimization may prove NOT to be a net
improvement due to the other consequences it introduces.
I am reasonably sure that one channel devices is the way to go. Whether
it is mono from the doorbell, stereo, or 7.1. Too many problems, too
little advantage.
none seems to be the perfect cherry. And, class D leaves me worrying
about sound quality and RFI (generated) -- esp when the loads aren't
close to the amp (e.g., the two channel case)
Pointers?
Put some high-frequency filtering at the output of the amplifier.
I'm concerned with the *bulk* that would involve (note the entire
device wants to be just a couple of cubic inches). It's alarming
how quickly that volume gets eaten up (electronics, connectors, etc.)
My original vision was for a single channel device bolted directly
to the driver. I.e., it's bulk hides in the speaker's envelope;
no long wires leading *to* the voice coil from the device, etc.
I.e., the two channel optimization may prove NOT to be a net
improvement due to the other consequences it introduces.
I am reasonably sure that one channel devices is the way to go. Whether
it is mono from the doorbell, stereo, or 7.1. Too many problems, too
little advantage.
The biggest problem comes with tabletop/countertop/bedside
deployments -- where the speakers tend to be *relatively*
lose together. You don't want to have to run *two* drops
to the same place.
Or, in our case, the pair of speakers above the kitchen sink
(separated by about 4 ft).
(The "boombox" option can typically be addressed by adding
components to the "enclosure" housing the speakers)
Don Y
Guest
Guest
Sun Jan 15, 2012 11:40 pm
Hi Tim,
On 1/10/2012 7:48 PM, Tim Williams wrote:
Quote:
"Don Y"<this_at_isnotme.com> wrote in message
news:jei14t$96h$1_at_speranza.aioe.org...
I'm not concerned with the choice of speaker. I.e., all of the value
added, here, is in the hardware and software designs. If someone opts
to tack a good/bad speaker onto one...<shrug> as long as it fits their
requirements, what do *I* care? :
My personal needs vary in fidelity, durability, etc. E.g., the speaker
used "for announcements" (someone is at the door; the garage door was
just opened; time to check the roast; etc.) can be of low fidelity
but must endure a harsh physical environment (i.e., without cone drying
out). OTOH, those with multimedia application will tend to want to
be of higher quality...
Ok, so it could be kind of all over, implementation dependent. That'll
news:jei14t$96h$1_at_speranza.aioe.org...
I'm not concerned with the choice of speaker. I.e., all of the value
added, here, is in the hardware and software designs. If someone opts
to tack a good/bad speaker onto one...<shrug> as long as it fits their
requirements, what do *I* care? :
My personal needs vary in fidelity, durability, etc. E.g., the speaker
used "for announcements" (someone is at the door; the garage door was
just opened; time to check the roast; etc.) can be of low fidelity
but must endure a harsh physical environment (i.e., without cone drying
out). OTOH, those with multimedia application will tend to want to
be of higher quality...
Ok, so it could be kind of all over, implementation dependent. That'll
Yup. As it should be, IMO. Let the end user trade dollars for
performance. Folks with "tin ears" or who just listen to talk
radio will care little for the quality of the driver.
Quote:
make loudness difficult to tack down, but maybe that's not such a big deal
after all. The PA speaker might be a cheap, tinny, relatively efficient
type, or outdoor compatible; the hi-fi types might be low efficiency, but
that might not be a problem for the casual iPod user who wants something
for quiet listening without those horrible earbuds.
after all. The PA speaker might be a cheap, tinny, relatively efficient
type, or outdoor compatible; the hi-fi types might be low efficiency, but
that might not be a problem for the casual iPod user who wants something
for quiet listening without those horrible earbuds.
Exactly. E.g., we often listen to "background music" in the
kitchen while preparing a meal. We don't need head banging
volumes but would prefer resonable *quality*.
Quote:
http://myweb.msoe.edu/williamstm/Images/ClassD_4.jpg
Ouch! Physically too large. I was hoping to tap into the market
created by battery powered, hand-held devices -- though my power
requirements tend to be an order of magnitude higher than most of
those (and the voltage/power available accordingly)
That circuit could be miniaturized quite a bit as-is; notice it's discrete
on a two layer board (the best I've ever made by hand, if I do say so
myself.. the layers lined up perfectly!). A couple drivers, or a whole
monolithic chip, should leave enough room for your receiver and DAC
business.
I can't imagine any popular monolithic solution would get any traction
if
it didn't have the distortion to sell it. The only thing I'd watch out
for is style -- open loop, closed loop, voltage mode, current mode,
carrier frequency, etc. These aspects will dominate performance and
fault
behavior.
What are the major tradeoffs with each? Remember the environment:
aside from assembly, there should problem with "shorted outputs"
unless a voice coil overheats/shorts -- in which case, the cost
of the speaker and labor to replace it might be high enough to
justify replacing the "amplifier" as well.
Yeah, it's not quite consumer material, but if you have to use BGAs and
such to fit the package, a dead circuit is pretty much throwaway to
anyone.
Ouch! Physically too large. I was hoping to tap into the market
created by battery powered, hand-held devices -- though my power
requirements tend to be an order of magnitude higher than most of
those (and the voltage/power available accordingly)
That circuit could be miniaturized quite a bit as-is; notice it's discrete
on a two layer board (the best I've ever made by hand, if I do say so
myself.. the layers lined up perfectly!). A couple drivers, or a whole
monolithic chip, should leave enough room for your receiver and DAC
business.
I can't imagine any popular monolithic solution would get any traction
if
it didn't have the distortion to sell it. The only thing I'd watch out
for is style -- open loop, closed loop, voltage mode, current mode,
carrier frequency, etc. These aspects will dominate performance and
fault
behavior.
What are the major tradeoffs with each? Remember the environment:
aside from assembly, there should problem with "shorted outputs"
unless a voice coil overheats/shorts -- in which case, the cost
of the speaker and labor to replace it might be high enough to
justify replacing the "amplifier" as well.
Yeah, it's not quite consumer material, but if you have to use BGAs and
such to fit the package, a dead circuit is pretty much throwaway to
anyone.
Yup. And, my point was, you aren't dicking with those
connections (intentionally) often. Not like "time to move
the hifi as we rearrange furniture". Nor are you likely
to encounter UNintentional changes ("oops! I tripped on
the speaker wires and pulled them out of their bindings!")
I.e., you might stress the network connection but not the
*internal* ones!
Quote:
As for amps, I don't know much about them beyond my own experience. Even
open loop can give reasonable fidelity, but protection circuitry is extra.
Closed loop cleans up the response, asymptotically, but usually leaves
distortion at higher frequencies, relating to the open-loop artifacts that
feedback isn't fast enough to clean up. (As with any audio, you get the
best results with the best of everything, and only then add NFB to make it
electrically perfect.)
Current mode is the best method for switching supplies in general, because
having first-order control over inductor current prevents any possible
fault problems. Unfortunately, speakers aren't current mode (well, most
of them*..), so a voltage-mode loop is required, which means the overall
response will be inductive at high frequencies, coming down to resistive
or voltage sourced at low frequencies. On the plus side, current control
is usually a first order system, so its dominant pole can be almost as
high as the clock frequency, impacting overall frequency response
minimally. With the inner loop keeping average current accurately at the
setpoint, linearity should be high, even if the PWM method is poor.
*A friend of mine built a variable impedance amplifier for the audiophile
circle. You can dial in the boominess at will. Some specially made
speakers respond quite well to high impedances, most are ridiculously
terrible!
open loop can give reasonable fidelity, but protection circuitry is extra.
Closed loop cleans up the response, asymptotically, but usually leaves
distortion at higher frequencies, relating to the open-loop artifacts that
feedback isn't fast enough to clean up. (As with any audio, you get the
best results with the best of everything, and only then add NFB to make it
electrically perfect.)
Current mode is the best method for switching supplies in general, because
having first-order control over inductor current prevents any possible
fault problems. Unfortunately, speakers aren't current mode (well, most
of them*..), so a voltage-mode loop is required, which means the overall
response will be inductive at high frequencies, coming down to resistive
or voltage sourced at low frequencies. On the plus side, current control
is usually a first order system, so its dominant pole can be almost as
high as the clock frequency, impacting overall frequency response
minimally. With the inner loop keeping average current accurately at the
setpoint, linearity should be high, even if the PWM method is poor.
*A friend of mine built a variable impedance amplifier for the audiophile
circle. You can dial in the boominess at will. Some specially made
speakers respond quite well to high impedances, most are ridiculously
terrible!
Hmmm.. I thought you always wanted to keep the damping factor as
high as practical (of course, the impedance of the speaker also
varies)
Quote:
I'm concerned with the efficacy and size of filters on the output.
Since space is *really* tight, even high frequency devices can
be (relatively) large.
If you can put the boards behind the speakers, this will be fine -- the
voice coils or magnets might get a bit toasty from the eddy currents,
Since space is *really* tight, even high frequency devices can
be (relatively) large.
If you can put the boards behind the speakers, this will be fine -- the
voice coils or magnets might get a bit toasty from the eddy currents,
Yes.
Quote:
which will hit you with quiescent current, but if it's not too much, no
big deal. This does rule out stereo amplifiers unless you're going to
have a panel connector for the other one.
big deal. This does rule out stereo amplifiers unless you're going to
have a panel connector for the other one.
Even a connector implies a *cable*. Then, I think the filter
becomes necessary.
Quote:
I grilled a turkey last night, over charcoal of course (anything else is
wasted time!). Soaked in brine and all that. (I'd use the grill to claim
hardcore Wisconsinism, but it's been downright muggy this year.) This
turkey sandwich is *delicious*. Oven roasted, never again
wasted time!). Soaked in brine and all that. (I'd use the grill to claim
hardcore Wisconsinism, but it's been downright muggy this year.) This
turkey sandwich is *delicious*. Oven roasted, never again
Some years ago, a friend roasted a pig (in his driveway). It
was, without a doubt, the best pork I'd ever eaten! THough
I admit some trepidation in taking those first bites: "Do I
*really* think this thing has been prepared and cooked properly???!"
Unfortunately, its not the sort of exercise you can repeat
without dozens of hungry mouths available!
josephkk
Guest
Guest
Mon Jan 16, 2012 5:18 am
On Sun, 15 Jan 2012 15:30:54 -0700, Don Y <this_at_isnotme.com> wrote:
Quote:
Put some high-frequency filtering at the output of the amplifier.
I'm concerned with the *bulk* that would involve (note the entire
device wants to be just a couple of cubic inches). It's alarming
how quickly that volume gets eaten up (electronics, connectors, etc.)
My original vision was for a single channel device bolted directly
to the driver. I.e., it's bulk hides in the speaker's envelope;
no long wires leading *to* the voice coil from the device, etc.
I.e., the two channel optimization may prove NOT to be a net
improvement due to the other consequences it introduces.
I am reasonably sure that one channel devices is the way to go. Whether
it is mono from the doorbell, stereo, or 7.1. Too many problems, too
little advantage.
The biggest problem comes with tabletop/countertop/bedside
deployments -- where the speakers tend to be *relatively*
lose together. You don't want to have to run *two* drops
to the same place.
Or, in our case, the pair of speakers above the kitchen sink
(separated by about 4 ft).
(The "boombox" option can typically be addressed by adding
components to the "enclosure" housing the speakers)
Understood. Small change in the module boundaries; one NIC, two (maybe
three) audio channels; for those (few?) locations. I had focused on the
distributed ceiling speakers. Oops.
Of course, maybe you do not need stereo at boom box locations. Only place
for 7.1 is the home theater. (?)
Different requirements result in different system specifications and thus
modularization. Do what supports your needs.
?-)
Don Y
Guest
Guest
Mon Jan 16, 2012 6:33 am
Hi Vladimir,
On 1/10/2012 7:19 PM, Vladimir Vassilevsky wrote:
Quote:
Don Y wrote:
Hi,
I've been designing a "network audio client" (aka "network loudspeaker")
and now have to select a suitable amplifier to use in it.
TPA2018
Hi,
I've been designing a "network audio client" (aka "network loudspeaker")
and now have to select a suitable amplifier to use in it.
TPA2018
<frown> Kinda wimpy -- 1(3)W into 8(4) ohms.
That seems to be typical of the sorts of devices I encounter...
as if intended for a small, battery powered PMP, etc. (e.g.,
the 6V power supply)
I guess the rationale is that you will "tolerate" class-D
for those extreme low power applications where nothing else
is possible. I seem to be operating at a point a bit too
high for most of these devices -- but still constrained
on power so unable to use AB style monolithic amps.
Don Y
Guest
Guest
Mon Jan 16, 2012 6:41 am
Hi Joseph,
On 1/15/2012 9:18 PM, josephkk wrote:
Quote:
On Sun, 15 Jan 2012 15:30:54 -0700, Don Y<this_at_isnotme.com> wrote:
Put some high-frequency filtering at the output of the amplifier.
I'm concerned with the *bulk* that would involve (note the entire
device wants to be just a couple of cubic inches). It's alarming
how quickly that volume gets eaten up (electronics, connectors, etc.)
My original vision was for a single channel device bolted directly
to the driver. I.e., it's bulk hides in the speaker's envelope;
no long wires leading *to* the voice coil from the device, etc.
I.e., the two channel optimization may prove NOT to be a net
improvement due to the other consequences it introduces.
I am reasonably sure that one channel devices is the way to go. Whether
it is mono from the doorbell, stereo, or 7.1. Too many problems, too
little advantage.
The biggest problem comes with tabletop/countertop/bedside
deployments -- where the speakers tend to be *relatively*
lose together. You don't want to have to run *two* drops
to the same place.
Or, in our case, the pair of speakers above the kitchen sink
(separated by about 4 ft).
(The "boombox" option can typically be addressed by adding
components to the "enclosure" housing the speakers)
Understood. Small change in the module boundaries; one NIC, two (maybe
three) audio channels; for those (few?) locations. I had focused on the
distributed ceiling speakers. Oops.
Put some high-frequency filtering at the output of the amplifier.
I'm concerned with the *bulk* that would involve (note the entire
device wants to be just a couple of cubic inches). It's alarming
how quickly that volume gets eaten up (electronics, connectors, etc.)
My original vision was for a single channel device bolted directly
to the driver. I.e., it's bulk hides in the speaker's envelope;
no long wires leading *to* the voice coil from the device, etc.
I.e., the two channel optimization may prove NOT to be a net
improvement due to the other consequences it introduces.
I am reasonably sure that one channel devices is the way to go. Whether
it is mono from the doorbell, stereo, or 7.1. Too many problems, too
little advantage.
The biggest problem comes with tabletop/countertop/bedside
deployments -- where the speakers tend to be *relatively*
lose together. You don't want to have to run *two* drops
to the same place.
Or, in our case, the pair of speakers above the kitchen sink
(separated by about 4 ft).
(The "boombox" option can typically be addressed by adding
components to the "enclosure" housing the speakers)
Understood. Small change in the module boundaries; one NIC, two (maybe
three) audio channels; for those (few?) locations. I had focused on the
distributed ceiling speakers. Oops.
It *really* feels "wrong" to support two channels. Where
do you stop? 2? 2+1? 4? etc.
And, when the amplifier is NOT required (e.g., when an external
amplifier is available and all you need is "line out"), then
you have to think about "is two actually *enough*"?
Depending on the device(s) chosen, I *could*, conceivably, stack
multiple "output cards" (since any package that has to present
"line out" jacks would need a larger enclosure). Likewise for
power amps.
Of course, the more channels you support, the tougher the
processing requirements (so you start needing more resources
ahead of the amp/DAC/etc.)
<grin> But, that's what makes it all *fun*!
Quote:
Of course, maybe you do not need stereo at boom box locations. Only place
for 7.1 is the home theater. (?)
Different requirements result in different system specifications and thus
modularization. Do what supports your needs.
for 7.1 is the home theater. (?)
Different requirements result in different system specifications and thus
modularization. Do what supports your needs.
Yup. I may have to resign myself to different hardware designs
to address the differing deployments. But, I should be able
to scale the software easily (which is the hardest part of such
a project, anyway!)
krw@att.bizzzzzzzzzzzz
Guest
Guest
Mon Jan 16, 2012 4:56 pm
On Sun, 15 Jan 2012 22:33:30 -0700, Don Y <this_at_isnotme.com> wrote:
Quote:
Hi Vladimir,
On 1/10/2012 7:19 PM, Vladimir Vassilevsky wrote:
Don Y wrote:
Hi,
I've been designing a "network audio client" (aka "network loudspeaker")
and now have to select a suitable amplifier to use in it.
TPA2018
frown> Kinda wimpy -- 1(3)W into 8(4) ohms.
That seems to be typical of the sorts of devices I encounter...
as if intended for a small, battery powered PMP, etc. (e.g.,
the 6V power supply)
I guess the rationale is that you will "tolerate" class-D
for those extreme low power applications where nothing else
is possible. I seem to be operating at a point a bit too
high for most of these devices -- but still constrained
on power so unable to use AB style monolithic amps.
On 1/10/2012 7:19 PM, Vladimir Vassilevsky wrote:
Don Y wrote:
Hi,
I've been designing a "network audio client" (aka "network loudspeaker")
and now have to select a suitable amplifier to use in it.
TPA2018
frown> Kinda wimpy -- 1(3)W into 8(4) ohms.
That seems to be typical of the sorts of devices I encounter...
as if intended for a small, battery powered PMP, etc. (e.g.,
the 6V power supply)
I guess the rationale is that you will "tolerate" class-D
for those extreme low power applications where nothing else
is possible. I seem to be operating at a point a bit too
high for most of these devices -- but still constrained
on power so unable to use AB style monolithic amps.
There are fairly high-power AB power amps, used in the automotive industry.
Cooling won't be easy and they may be hard to find, onesy-twosy, though.
josephkk
Guest
Guest
Tue Jan 17, 2012 11:34 am
On Sun, 15 Jan 2012 22:41:04 -0700, Don Y <this_at_isnotme.com> wrote:
Quote:
Hi Joseph,
On 1/15/2012 9:18 PM, josephkk wrote:
On Sun, 15 Jan 2012 15:30:54 -0700, Don Y<this_at_isnotme.com> wrote:
snip
The biggest problem comes with tabletop/countertop/bedside
deployments -- where the speakers tend to be *relatively*
lose together. You don't want to have to run *two* drops
to the same place.
Or, in our case, the pair of speakers above the kitchen sink
(separated by about 4 ft).
(The "boombox" option can typically be addressed by adding
components to the "enclosure" housing the speakers)
Understood. Small change in the module boundaries; one NIC, two (maybe
three) audio channels; for those (few?) locations. I had focused on the
distributed ceiling speakers. Oops.
It *really* feels "wrong" to support two channels. Where
do you stop? 2? 2+1? 4? etc.
And, when the amplifier is NOT required (e.g., when an external
amplifier is available and all you need is "line out"), then
you have to think about "is two actually *enough*"?
On 1/15/2012 9:18 PM, josephkk wrote:
On Sun, 15 Jan 2012 15:30:54 -0700, Don Y<this_at_isnotme.com> wrote:
snip
The biggest problem comes with tabletop/countertop/bedside
deployments -- where the speakers tend to be *relatively*
lose together. You don't want to have to run *two* drops
to the same place.
Or, in our case, the pair of speakers above the kitchen sink
(separated by about 4 ft).
(The "boombox" option can typically be addressed by adding
components to the "enclosure" housing the speakers)
Understood. Small change in the module boundaries; one NIC, two (maybe
three) audio channels; for those (few?) locations. I had focused on the
distributed ceiling speakers. Oops.
It *really* feels "wrong" to support two channels. Where
do you stop? 2? 2+1? 4? etc.
And, when the amplifier is NOT required (e.g., when an external
amplifier is available and all you need is "line out"), then
you have to think about "is two actually *enough*"?
Maybe the module boundary should be in terms of streams.
Quote:
Depending on the device(s) chosen, I *could*, conceivably, stack
multiple "output cards" (since any package that has to present
"line out" jacks would need a larger enclosure). Likewise for
power amps.
And one of the streams could be 5.1 digital.
Quote:
Of course, the more channels you support, the tougher the
processing requirements (so you start needing more resources
ahead of the amp/DAC/etc.)
grin> But, that's what makes it all *fun*!
Bloody straight.
Quote:
Of course, maybe you do not need stereo at boom box locations. Only place
for 7.1 is the home theater. (?)
Different requirements result in different system specifications and thus
modularization. Do what supports your needs.
Yup. I may have to resign myself to different hardware designs
to address the differing deployments. But, I should be able
to scale the software easily (which is the hardest part of such
a project, anyway!)
If you overlay the various deployments and try to factor that for
modularization you may find your happy place.
?-)
Don Y
Guest
Guest
Tue Jan 17, 2012 8:55 pm
Hi Joseph,
On 1/17/2012 3:34 AM, josephkk wrote:
Quote:
The biggest problem comes with tabletop/countertop/bedside
deployments -- where the speakers tend to be *relatively*
lose together. You don't want to have to run *two* drops
to the same place.
Or, in our case, the pair of speakers above the kitchen sink
(separated by about 4 ft).
(The "boombox" option can typically be addressed by adding
components to the "enclosure" housing the speakers)
Understood. Small change in the module boundaries; one NIC, two (maybe
three) audio channels; for those (few?) locations. I had focused on the
distributed ceiling speakers. Oops.
It *really* feels "wrong" to support two channels. Where
do you stop? 2? 2+1? 4? etc.
And, when the amplifier is NOT required (e.g., when an external
amplifier is available and all you need is "line out"), then
you have to think about "is two actually *enough*"?
Maybe the module boundary should be in terms of streams.
deployments -- where the speakers tend to be *relatively*
lose together. You don't want to have to run *two* drops
to the same place.
Or, in our case, the pair of speakers above the kitchen sink
(separated by about 4 ft).
(The "boombox" option can typically be addressed by adding
components to the "enclosure" housing the speakers)
Understood. Small change in the module boundaries; one NIC, two (maybe
three) audio channels; for those (few?) locations. I had focused on the
distributed ceiling speakers. Oops.
It *really* feels "wrong" to support two channels. Where
do you stop? 2? 2+1? 4? etc.
And, when the amplifier is NOT required (e.g., when an external
amplifier is available and all you need is "line out"), then
you have to think about "is two actually *enough*"?
Maybe the module boundary should be in terms of streams.
The problem inherently defies a simple partitioning.
E.g., if you want to drive speakers directly, you
partition the streams differently than if you want
to drive a "typical" home theater system (i.e., all
of the interfaces in a single location to connect
to external kit).
The degenerate case -- one channel, one speaker -- is the
obvious building block. But, doesn't lend itself well to
network deployment (esp wired networks).
Quote:
Depending on the device(s) chosen, I *could*, conceivably, stack
multiple "output cards" (since any package that has to present
"line out" jacks would need a larger enclosure). Likewise for
power amps.
And one of the streams could be 5.1 digital.
multiple "output cards" (since any package that has to present
"line out" jacks would need a larger enclosure). Likewise for
power amps.
And one of the streams could be 5.1 digital.
The CODEC I've designed really only wants to deal with two
audio "channels", at most. (Yes, I could change that)
Consider, the more "channels" you support in the stream,
the more resources you implicitly require on the ends of
that stream.
Eg., if you pack 5.1 into a single stream, then the
client device has to be able to unpack and DECODE
all of those streams in the same "unit time" that it
could otherwise have been responsible for a *single*
(or, perhaps *pair* of) "channel".
I.e., you can't just arbitrarily scale up the "width"
of each stream without consequences on the clients
(and the goal is to make the clients *really* simple
and inexpensive)
Quote:
Of course, maybe you do not need stereo at boom box locations. Only place
for 7.1 is the home theater. (?)
Different requirements result in different system specifications and thus
modularization. Do what supports your needs.
Yup. I may have to resign myself to different hardware designs
to address the differing deployments. But, I should be able
to scale the software easily (which is the hardest part of such
a project, anyway!)
If you overlay the various deployments and try to factor that for
modularization you may find your happy place.
for 7.1 is the home theater. (?)
Different requirements result in different system specifications and thus
modularization. Do what supports your needs.
Yup. I may have to resign myself to different hardware designs
to address the differing deployments. But, I should be able
to scale the software easily (which is the hardest part of such
a project, anyway!)
If you overlay the various deployments and try to factor that for
modularization you may find your happy place.
(sigh) Yes. The problem is trying to be "considerate"
(accommodating?) of future users' needs. I could, instead,
just focus on *my* needs and offer *my* implementations as
"reference designs" and let other folks "roll their own".
IME, this is too high a bar for many people to reach.
It seems far easier for people to repeat someone else's
success and make *minor* changes than to try to "grok"
the underlying truths and extrapolate those to another
implementation. Esp when there are lots of subtleties
in the design that they may not be qualified to understand
or accommodate (in another implementation).
<frown>
josephkk
Guest
Guest
Wed Jan 18, 2012 4:10 am
On Tue, 17 Jan 2012 12:55:03 -0700, Don Y <this_at_isnotme.com> wrote:
Quote:
And, when the amplifier is NOT required (e.g., when an external
amplifier is available and all you need is "line out"), then
you have to think about "is two actually *enough*"?
Maybe the module boundary should be in terms of streams.
The problem inherently defies a simple partitioning.
E.g., if you want to drive speakers directly, you
partition the streams differently than if you want
to drive a "typical" home theater system (i.e., all
of the interfaces in a single location to connect
to external kit).
Yes, it becomes a matter of tradeoffs. If you set up to optimize for one
or two cases other cases may become intractable. It is not clear of there
is a sufficiently flexible answer to do most cases reasonably well.
Quote:
The degenerate case -- one channel, one speaker -- is the
obvious building block. But, doesn't lend itself well to
network deployment (esp wired networks).
Depending on the device(s) chosen, I *could*, conceivably, stack
multiple "output cards" (since any package that has to present
"line out" jacks would need a larger enclosure). Likewise for
power amps.
And one of the streams could be 5.1 digital.
The CODEC I've designed really only wants to deal with two
audio "channels", at most. (Yes, I could change that)
Consider, the more "channels" you support in the stream,
the more resources you implicitly require on the ends of
that stream.
Eg., if you pack 5.1 into a single stream, then the
client device has to be able to unpack and DECODE
all of those streams in the same "unit time" that it
could otherwise have been responsible for a *single*
(or, perhaps *pair* of) "channel".
I seem to have been unclear again. The 5.1 (SPDIF) stream goes to a home
theater unit that does the rest from just the digital stream.
Quote:
I.e., you can't just arbitrarily scale up the "width"
of each stream without consequences on the clients
(and the goal is to make the clients *really* simple
and inexpensive)
Of course, maybe you do not need stereo at boom box locations. Only place
for 7.1 is the home theater. (?)
Different requirements result in different system specifications and thus
modularization. Do what supports your needs.
Yup. I may have to resign myself to different hardware designs
to address the differing deployments. But, I should be able
to scale the software easily (which is the hardest part of such
a project, anyway!)
If you overlay the various deployments and try to factor that for
modularization you may find your happy place.
(sigh) Yes. The problem is trying to be "considerate"
(accommodating?) of future users' needs. I could, instead,
just focus on *my* needs and offer *my* implementations as
"reference designs" and let other folks "roll their own".
IME, this is too high a bar for many people to reach.
It seems far easier for people to repeat someone else's
success and make *minor* changes than to try to "grok"
the underlying truths and extrapolate those to another
implementation. Esp when there are lots of subtleties
in the design that they may not be qualified to understand
or accommodate (in another implementation).
frown
Perhaps if you place the design in creative commons or such, you may wish
to place a trio of designs and discuss the tradeoffs for selecting one
basis or another for the other users who wish to adapt it. A lot more
work that way though.
?-)
Don Y
Guest
Guest
Wed Jan 18, 2012 5:32 am
Hi Joseph,
On 1/17/2012 8:10 PM, josephkk wrote:
Quote:
On Tue, 17 Jan 2012 12:55:03 -0700, Don Y<this_at_isnotme.com> wrote:
Depending on the device(s) chosen, I *could*, conceivably, stack
multiple "output cards" (since any package that has to present
"line out" jacks would need a larger enclosure). Likewise for
power amps.
And one of the streams could be 5.1 digital.
The CODEC I've designed really only wants to deal with two
audio "channels", at most. (Yes, I could change that)
Consider, the more "channels" you support in the stream,
the more resources you implicitly require on the ends of
that stream.
Eg., if you pack 5.1 into a single stream, then the
client device has to be able to unpack and DECODE
all of those streams in the same "unit time" that it
could otherwise have been responsible for a *single*
(or, perhaps *pair* of) "channel".
I seem to have been unclear again. The 5.1 (SPDIF) stream goes to a home
theater unit that does the rest from just the digital stream.
Depending on the device(s) chosen, I *could*, conceivably, stack
multiple "output cards" (since any package that has to present
"line out" jacks would need a larger enclosure). Likewise for
power amps.
And one of the streams could be 5.1 digital.
The CODEC I've designed really only wants to deal with two
audio "channels", at most. (Yes, I could change that)
Consider, the more "channels" you support in the stream,
the more resources you implicitly require on the ends of
that stream.
Eg., if you pack 5.1 into a single stream, then the
client device has to be able to unpack and DECODE
all of those streams in the same "unit time" that it
could otherwise have been responsible for a *single*
(or, perhaps *pair* of) "channel".
I seem to have been unclear again. The 5.1 (SPDIF) stream goes to a home
theater unit that does the rest from just the digital stream.
Ooooo.... that's a clever idea! I.e., support digital
outputs for those cases - instead of multiple analog
outputs!
This could considerably simplify those "drops" -- since
there is virtually no DSP work done in the client. It
just becomes a simple transport protocol...
(unfortunately, it doesn't apply to *all* cases)
elektroda.net NewsGroups Forum Index - Electronics Design - "Efficient" audio amp selection
