Open-source USB interface: Audio Widget - Page 134 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Source

Digital Source Digital Players and Recorders: CD , SACD , Tape, Memory Card, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 8th March 2012, 04:39 PM   #1331
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
Quote:
Originally Posted by GeorgeBoudreau View Post
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.
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
__________________
My Photostream:http://www.flickr.com/photos/linux-works/
  Reply With Quote
Old 8th March 2012, 04:44 PM   #1332
diyAudio Member
 
Join Date: Nov 2010
Location: Toronto
"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.
  Reply With Quote
Old 8th March 2012, 04:51 PM   #1333
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
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
__________________
My Photostream:http://www.flickr.com/photos/linux-works/
  Reply With Quote
Old 8th March 2012, 04:59 PM   #1334
diyAudio Member
 
Join Date: Nov 2010
Location: Toronto
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.
  Reply With Quote
Old 8th March 2012, 05:01 PM   #1335
diyAudio Member
 
Join Date: Nov 2010
Location: Toronto
oh.. I have a WM8741 single DAC card with I2C control bus at the 90% mark. I never took it any further as it needs a configuration system to work properly.
  Reply With Quote
Old 8th March 2012, 05:28 PM   #1336
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
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.
__________________
My Photostream:http://www.flickr.com/photos/linux-works/
  Reply With Quote
Old 8th March 2012, 07:17 PM   #1337
diyAudio Member
 
Join Date: Nov 2010
Location: Toronto
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
  Reply With Quote
Old 8th March 2012, 07:40 PM   #1338
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
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?
__________________
My Photostream:http://www.flickr.com/photos/linux-works/
  Reply With Quote
Old 8th March 2012, 07:49 PM   #1339
diyAudio Member
 
Join Date: Nov 2010
Location: Toronto
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.
  Reply With Quote
Old 8th March 2012, 08:29 PM   #1340
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
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.
__________________
My Photostream:http://www.flickr.com/photos/linux-works/
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Async 192Khz USB - the SDR-Widget collaborative project SunRa PC Based 5 26th April 2011 06:38 PM
usb audio interface david12 Equipment & Tools 14 10th October 2010 02:58 AM
Cheap Audio Interface (USB?) to PC agm2003 Instruments and Amps 11 16th September 2007 07:48 AM
Open call for suggestions on Open Source DIY Audio Design gfergy Everything Else 1 15th April 2007 07:33 AM
USB Interface Perfect?- Computer Audio fmak Digital Source 3 4th December 2004 10:24 PM


New To Site? Need Help?

All times are GMT. The time now is 12:24 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2