I see. I just got it yesterday, so I am not too keen on sending it anywhere, if you understand
Maybe it would be easier to make a workaround for TE8802L in the Linux kernel instead, as I suppose the USB Audio Class 2 implementation in Linux is correct?
Can you explain what the bug/problem is with TE8802L?
i think its unfair to ask him to do so, hes not even building one for himself afaik and there would be a fair bit of money involved. i'll contact Brian and see what we can arrange, but i actually dont think it will be possible, they may have removed the need for an NDA to get the datasheet, but i still think you would have issues distributing chips and the datasheet. i'll see what he says anyway.
didnt you do anything with them either George?
didnt you do anything with them either George?
Last edited:
I actually had a 9012 + buffer board laid out last spring, April 2011, and was going to turn out a few but I got side tracked
Part of the problem with the more sophisticated devices is the need to set up the internals registers. This required an I2C interface between the processor and the dac as well as a user interface running on the PC.
The Atmel processor has the I2C capability and there was/is a HID connection but it requires more than 2 traces to the DAC to make this work.. lots of firmware mods on the processor plus a well defined user interface running on the pc.
I will dig deeper for the chips but they may have become lonely and looked for a friendlier developer.
George
Part of the problem with the more sophisticated devices is the need to set up the internals registers. This required an I2C interface between the processor and the dac as well as a user interface running on the PC.
The Atmel processor has the I2C capability and there was/is a HID connection but it requires more than 2 traces to the DAC to make this work.. lots of firmware mods on the processor plus a well defined user interface running on the pc.
I will dig deeper for the chips but they may have become lonely and looked for a friendlier developer.
George
if you need i2c help, I might be able to lend a hand. we can do without a pc (always good to remove the pesky computer from the equation) and have an IR and LCD control for things that need controlling. or local switches or a local UI.
computers are great for sourcing data streams but I'd rather not let them be the sole source of remote control. *a* source, but not even the primary one; just there for when a webserver needs to control the 'appliance'.
computers are great for sourcing data streams but I'd rather not let them be the sole source of remote control. *a* source, but not even the primary one; just there for when a webserver needs to control the 'appliance'.
The I2C code is not the problem and we have tested code to drive the bus. It is modifying the HID class to accept a 'standardized' configuration language from the user interface.
You don't want the hassles of maintaining separate code versions for every DAC on the market. There needs to be a mini interpreter that reads the HID data and translates the information into the register addressing and data format.
Grab the data sheets from every dac you can find and make a spreadsheet of the register function/addr/data etc. Then squint your eyes and look at the spreadsheet. ( squinting reduces resolution and you only see gross information ) Is there commonalities that can be exploited? How about I2C addr/reg addr/ data. On the use end you don't want to be bothered with that level of detail and you only want to see the filter selection with a check box, push accept and the DAC is updated.
Since each DAC is unique the gui program would query the dac for an ID.. oh say 9012, 9018, 1796, 8741 with 0000 meaning the DAC has no user configurable parameters.. 9023/5012 etc. It would read the configuration file for that DAC and present the use with available choices.
One gui with runtime configuration beats the crap out 10 custom programs.
George
You don't want the hassles of maintaining separate code versions for every DAC on the market. There needs to be a mini interpreter that reads the HID data and translates the information into the register addressing and data format.
Grab the data sheets from every dac you can find and make a spreadsheet of the register function/addr/data etc. Then squint your eyes and look at the spreadsheet. ( squinting reduces resolution and you only see gross information
) Is there commonalities that can be exploited? How about I2C addr/reg addr/ data. On the use end you don't want to be bothered with that level of detail and you only want to see the filter selection with a check box, push accept and the DAC is updated.Since each DAC is unique the gui program would query the dac for an ID.. oh say 9012, 9018, 1796, 8741 with 0000 meaning the DAC has no user configurable parameters.. 9023/5012 etc. It would read the configuration file for that DAC and present the use with available choices.
One gui with runtime configuration beats the crap out 10 custom programs.
George
abstracting it is great, if that's do-able. how much intersection *is* there that would be common?
if there's enough core common stuff, that's great; but I'm guessing that to fully 'manage' each dac chips needs a human tuned app and gui for each that is streamlined for each. no other way around it. each time I hear of someone trying a one-size-fits-all remote mgmt approach, it falls apart beyond some simple common core set of attributes.
its the same in networking (my primary field). there is some overlap in routers and switches, but to really manage the device you need device plugins and those are written by the vendor and those manage down to the 'register' level, so to speak. and the gui or app to really control them is custom written or it generally is too broad to be of use. its just life in the very device-specific world: you have to have a custom UI for each thing, pretty much.
if there's enough core common stuff, that's great; but I'm guessing that to fully 'manage' each dac chips needs a human tuned app and gui for each that is streamlined for each. no other way around it. each time I hear of someone trying a one-size-fits-all remote mgmt approach, it falls apart beyond some simple common core set of attributes.
its the same in networking (my primary field). there is some overlap in routers and switches, but to really manage the device you need device plugins and those are written by the vendor and those manage down to the 'register' level, so to speak. and the gui or app to really control them is custom written or it generally is too broad to be of use. its just life in the very device-specific world: you have to have a custom UI for each thing, pretty much.
great idea in theory, but in practice insisting on such a solution will paralyze development, as it seems to have done... =D
each new dac chip builds on the last and thats just in the same manufacturer or type of dac chip, there are some very simple core attributes, but i'm guessing in general the manufacturers do not talk to each other (they cant, their lawyers wont let them and you may even expose yourself to legal action just by creating a common database that lists it all in the one place) but also due to varying depths of feature-sets each function even if its the same, is likely to sit in a different place in the tree and apply to a different physical and logical pin location. i just dont see it becoming a reality i'm afraid.
so just present the user with a simple feature set and provide a header for comms in case someone wants to go past the surface.
each new dac chip builds on the last and thats just in the same manufacturer or type of dac chip, there are some very simple core attributes, but i'm guessing in general the manufacturers do not talk to each other (they cant, their lawyers wont let them and you may even expose yourself to legal action just by creating a common database that lists it all in the one place) but also due to varying depths of feature-sets each function even if its the same, is likely to sit in a different place in the tree and apply to a different physical and logical pin location. i just dont see it becoming a reality i'm afraid.
so just present the user with a simple feature set and provide a header for comms in case someone wants to go past the surface.
Last edited:
in fact, just trying to commonize things like spdif transmitter or receiver chips (easier job than dacs, in some ways) becomes a nearly-null intersection set
the controller really should be able to query for the device type (type, serial #, product hw version, fw version, board rev, etc!) and then use its case logic to determine what dialect to use to speak to the device.
OT: I always thought it would be nice to bring the concept of discovery or auto-topology to audio. in networking, you can (via various protocols) discover and draw a map of all things connected. wouldn't it be cool to be able to query 'thru' things and learn what is connected? it would assume there *is* a mgmt path to each device (inband or out of band); but more and more devices do have some kind of mgmt interface to them.
sorry for the OT but its slightly related in that we can have various dacs as leaf nodes hanging off this 'digital audio interface' (usb to i2s or usb to spdif).
the controller really should be able to query for the device type (type, serial #, product hw version, fw version, board rev, etc!) and then use its case logic to determine what dialect to use to speak to the device.
OT: I always thought it would be nice to bring the concept of discovery or auto-topology to audio. in networking, you can (via various protocols) discover and draw a map of all things connected. wouldn't it be cool to be able to query 'thru' things and learn what is connected? it would assume there *is* a mgmt path to each device (inband or out of band); but more and more devices do have some kind of mgmt interface to them.
sorry for the OT but its slightly related in that we can have various dacs as leaf nodes hanging off this 'digital audio interface' (usb to i2s or usb to spdif).
ok, lets talk about this a little. what you propose is the 'peek/poke' or 'get/set' model where you define the mgmt attributes as simple variables that can take values. SNMP is built entirely on that and it pretty much works, as a network mgmt protocol for a huge variety of net-connected devices. but its simplicity also limits it; the idea of atomic sets (doing a whole bunch of things at once or nothing at all) is hard and problematic. 'undo' is also not really supported or the rollback model. and what about conditionals? suppose you only want to take action if something went right or went wrong? suppose you need to send some values, wait a bit of time, check things and do other things based on that? what if there is a polling need; to spin on a value until it changes? get/set won't be strong enough for these kinds of things.
eventually, to do anything other than really simple things, you need to script. simple set/get commands are really not enough.
it gets back to my assertion that any valuable app will make use of primitives of get/set but also need to have their own app-specific code around that to be really useful.
get/set of regs and values is a good start, though; but I would not expect this to be the end of it
"the controller really should be able to query for the device type (type, serial #, product hw version, fw version, board rev, etc!) and then use its case logic to determine what dialect to use to speak to the device."
This is what I had in mind. The lining up the datasheets was only to look for common data formats. But in the end the 'configuration file' was to contain screen text, address, data format etc that the gui could work with and send to the Atmel processor via the USB HID class in a standardized format. The firmware would take this data and push it out to the DAC only needing I2C addr/reg addr/ data count/ data. You do not want too much sophistication in the firmware just enough to do the read/write. All the heavy lifting should be done in the gui.
This is what I had in mind. The lining up the datasheets was only to look for common data formats. But in the end the 'configuration file' was to contain screen text, address, data format etc that the gui could work with and send to the Atmel processor via the USB HID class in a standardized format. The firmware would take this data and push it out to the DAC only needing I2C addr/reg addr/ data count/ data. You do not want too much sophistication in the firmware just enough to do the read/write. All the heavy lifting should be done in the gui.
agreed with the gui being the smart part. that's the 'manager' and the 'agent' is just the part that receives the thin protocol, does the get/set and then returns success/failure.
all the smarts has to be 'up north' at the app.
I don't know much about usb hid; but is this a strong enough protocol (and user apps) to really manage down to the dac (and transmitter) level?
for example, I'm playing with a wm8741 these days and there is an anti-clipping (gibbs fix, sort of?) switch in the dac. where, on a pc platform, would a user be able to see or flip the value of this kind of dac feature? is an audio player expected to see this? thru a mixer interface?? is that really proper? if not mixer, where else? some control panel?
yeah, I ask a lot of questions for a guy from new jersey
all the smarts has to be 'up north' at the app.
I don't know much about usb hid; but is this a strong enough protocol (and user apps) to really manage down to the dac (and transmitter) level?
for example, I'm playing with a wm8741 these days and there is an anti-clipping (gibbs fix, sort of?) switch in the dac. where, on a pc platform, would a user be able to see or flip the value of this kind of dac feature? is an audio player expected to see this? thru a mixer interface?? is that really proper? if not mixer, where else? some control panel?
yeah, I ask a lot of questions for a guy from new jersey
This is exactly what I propose.
The user wants to enable anti-clipping. He/she fires up the gui, it queries the DAC and inhales the configuration for the 8741. You click on the 'anti-clipping' box and the gui formats the data and sends to the Atmel processor using the HID class. The processor takes the data it just received extracts I2C addr/register addr/data and writes to the DAC. To the processor it is just a I2C data write and no more.
As long as the processor only has to worry about I2C data formatting there will be no DAC specific tasks. Unless I am totally off base I see this as a clean method of reading/writing DAC registers.
The user wants to enable anti-clipping. He/she fires up the gui, it queries the DAC and inhales the configuration for the 8741. You click on the 'anti-clipping' box and the gui formats the data and sends to the Atmel processor using the HID class. The processor takes the data it just received extracts I2C addr/register addr/data and writes to the DAC. To the processor it is just a I2C data write and no more.
As long as the processor only has to worry about I2C data formatting there will be no DAC specific tasks. Unless I am totally off base I see this as a clean method of reading/writing DAC registers.
ok, lets go more advanced
how does this usb dialog do scripting or conditionals? suppose you have to read one line's value, decide and fork to 2 different sub-dialogs? if the 96k line says high, you set foo1 to bar1 and foo2 to bar2 but if its not 96k==high, then you do something else. this is likely, too; the 8741 has different filter settings and if its 48k and below, you do A, if its middle range (48..96) you do B and if its high range you do C. this should not be user-clickable as it would be a PITA to have to have the user change things that should auto set by themselves; but who should auto-set it? if you take the IQ out of the dac, for example, and push all the responsibility up to the client layers, is that really effective?
I'm just not convinced that toggle buttons and such are strong enough primitives for complex device mgmt.
how does this usb dialog do scripting or conditionals? suppose you have to read one line's value, decide and fork to 2 different sub-dialogs? if the 96k line says high, you set foo1 to bar1 and foo2 to bar2 but if its not 96k==high, then you do something else. this is likely, too; the 8741 has different filter settings and if its 48k and below, you do A, if its middle range (48..96) you do B and if its high range you do C. this should not be user-clickable as it would be a PITA to have to have the user change things that should auto set by themselves; but who should auto-set it? if you take the IQ out of the dac, for example, and push all the responsibility up to the client layers, is that really effective?
I'm just not convinced that toggle buttons and such are strong enough primitives for complex device mgmt.
You may be making this too complicated. The DAC accepts writes to registers with data of fixed format. The processor receives data from the user in a very simple format DAC addr/register addr/ register data and writes to the DAC. The user interface is responsible for displaying valid choices and accepting input.
Ignore the details of the USB HID interface and the firmware needed to handle it and the I2C bus work. It all boils down to what bit I flip to enable this function. Like the Linux kernel build menu you are presented with choices based on the previous selection. All of the work is done by the gui.. as much hand holding as you want to write in.
George
Ignore the details of the USB HID interface and the firmware needed to handle it and the I2C bus work. It all boils down to what bit I flip to enable this function. Like the Linux kernel build menu you are presented with choices based on the previous selection. All of the work is done by the gui.. as much hand holding as you want to write in.
George
again, that is static and not powerful enough.
suppose you need to set filters based on the samplerate (or some line on a chip). how do you propose a simple set-only dialog will work? you need to query down to the device, get some state info, make decisions, set some state, maybe query more and so on. this is far more than a simple config file download.
there will be times when a static config download will be enough. but what about the times when its not enough?
look at the wolfson spdif receiver in software mode. you could argue that the device programming belongs on the device's board and the way it has to deal with 176.4 is a strange software dance. if you keep the leaf devices dumb then this kind of dialog has to go between the host and the device and simple get/set isn't strong enough. if the device has local processing for control, some stuff could be kept local and the more useful things be exported as a remote mgmt interface.
can you give some examples of how a simple config download would be useful and why the host really has to be involved in this and not a local 'chip helper' controller?
suppose you need to set filters based on the samplerate (or some line on a chip). how do you propose a simple set-only dialog will work? you need to query down to the device, get some state info, make decisions, set some state, maybe query more and so on. this is far more than a simple config file download.
there will be times when a static config download will be enough. but what about the times when its not enough?
look at the wolfson spdif receiver in software mode. you could argue that the device programming belongs on the device's board and the way it has to deal with 176.4 is a strange software dance. if you keep the leaf devices dumb then this kind of dialog has to go between the host and the device and simple get/set isn't strong enough. if the device has local processing for control, some stuff could be kept local and the more useful things be exported as a remote mgmt interface.
can you give some examples of how a simple config download would be useful and why the host really has to be involved in this and not a local 'chip helper' controller?
The only way you can have a system you propose is to have separate firmware for every DAC you want to support and hardwire rules for that device into the firmware. The processor would have to deal with any sample rate specific settings and the user interface would be handle the mundane functions.
If you want to write a module that could be customized for each dac out there it will be quite a task.
If you want to write a module that could be customized for each dac out there it will be quite a task.
I do think that complex 'manageable' systems (ie, ones that can be software controlled) do need local processors to do the intimate device level things. those know the registers and how to twiddle the bits in the right way, right order, right timing, right dependancies. they manage the device and only export some simple things. those things would be higher level concepts than get/set registers.
the abstraction that is 'useful' to the users is the only thing that would be exported as an api, as it were, to the manager/user. turning on anti-clipping or setting a volume level in dB (some chips have that, some don't) are high level concepts. those are more easily shown on mixer panels or guis. and the host does not have to know much about HOW the anti-clipping effect is changed; he just says 'change it from off to on' and the lower hardware layers deal with the how.
one benefit of keeping that special knowledge down in the device is that you do it once and all host types benefit for free. they can't get it wrong, either; since they don't control the 'hows' of the operation. a windows, mac or linux user would say 'anti clipping= off' and they'd push down the same macro level command. that one bit of hardware would translate that into the register stuff, do it and return a status.
we're only arguing about *where* various translations occur in the software stacks. there is a clear architectural benefit in having that translater layer exist once and as close to the hardware as possible. one instance of it right in the hardware box; and no instances of it in any mac/pc/linux app stack.
the abstraction that is 'useful' to the users is the only thing that would be exported as an api, as it were, to the manager/user. turning on anti-clipping or setting a volume level in dB (some chips have that, some don't) are high level concepts. those are more easily shown on mixer panels or guis. and the host does not have to know much about HOW the anti-clipping effect is changed; he just says 'change it from off to on' and the lower hardware layers deal with the how.
one benefit of keeping that special knowledge down in the device is that you do it once and all host types benefit for free. they can't get it wrong, either; since they don't control the 'hows' of the operation. a windows, mac or linux user would say 'anti clipping= off' and they'd push down the same macro level command. that one bit of hardware would translate that into the register stuff, do it and return a status.
we're only arguing about *where* various translations occur in the software stacks. there is a clear architectural benefit in having that translater layer exist once and as close to the hardware as possible. one instance of it right in the hardware box; and no instances of it in any mac/pc/linux app stack.