Does anyone have (or can take) a hi-res photo of the miniDSP board? I just want to get an idea of the chips used.
Thanks 🙂
Thanks 🙂
You could just ask what the chips are. It's not a secret. 🙂
The heart of the operation on the miniDSP board is an Analog ADAU1701.
Over on the miniDSP forum the device complements on some of the other boards have been discussed.
Cheers,
Dave.
The heart of the operation on the miniDSP board is an Analog ADAU1701.
Over on the miniDSP forum the device complements on some of the other boards have been discussed.
Cheers,
Dave.
Thanks, I knew about the ADAU1701. I'm more interested in the 'support' chips, ie. how they have implemented the platform. There's a whole header (J2/Expansion header #1 in the manual) that is undocumented. If it's a similar implementation to the ADAU1701 Eval board, it might be possible to use AD's USBi adaptor to program the board with SigmaStudio.
(Of course I know they've stated that SigmaStudio is 'not supported', and that any such actions would void warranty.)
While miniDSP's plugin idea is nice, it doesn't offer the degree of customisation I'd like. I'm happy to sacrifice a few PEQs for other purposes.
🙂
(Of course I know they've stated that SigmaStudio is 'not supported', and that any such actions would void warranty.)
While miniDSP's plugin idea is nice, it doesn't offer the degree of customisation I'd like. I'm happy to sacrifice a few PEQs for other purposes.
🙂
@fb,
I may sound like I'm making a statement that's common knowledge (i.e. makes sense to us) but you do realize that this is the manufacturer's forum, right? Maybe not the best to ask how to reverse engineer our boards... 😕
FYI, our platform is not based on the ADAU1701 dev platform (i.e. uC) which wouldn't let you flash a different firmware on the IC. With a bit of knowledge, you would realize that when it comes to microcontroller, it doesn't matter if it's a PIC, an Atmel or whatever.. If you don't have a similar firmware embedded inside, you're going to go nowhere when it comes to programming the device. (even how would you control it?)
Please read the following link for more info about the reason why firmware is not customizable and why our board is not a devkit: MiniDSP - Can you provide an IDE for us to customize our code?
By a simple request of respect, I would therefore gently ask that you keep such reverse engineering discussions outside this forum.
Thanks for your understanding.
DevTeam
I may sound like I'm making a statement that's common knowledge (i.e. makes sense to us) but you do realize that this is the manufacturer's forum, right? Maybe not the best to ask how to reverse engineer our boards... 😕
FYI, our platform is not based on the ADAU1701 dev platform (i.e. uC) which wouldn't let you flash a different firmware on the IC. With a bit of knowledge, you would realize that when it comes to microcontroller, it doesn't matter if it's a PIC, an Atmel or whatever.. If you don't have a similar firmware embedded inside, you're going to go nowhere when it comes to programming the device. (even how would you control it?)
Please read the following link for more info about the reason why firmware is not customizable and why our board is not a devkit: MiniDSP - Can you provide an IDE for us to customize our code?
By a simple request of respect, I would therefore gently ask that you keep such reverse engineering discussions outside this forum.
Thanks for your understanding.
DevTeam
internecine,
Thanks, I stumbled on those at some point after posting. 🙂
miniDSP,
I apologise, I'm not coming at this from a 'for profit' motive if that's what you're suggesting. It's a fairly natural thing for DIYers to want to maximise the potential of a piece of hardware. Since starting this thread I have purchased 2 miniDSP boards, instead of the 1 I would require if the plugins were more flexible.
I understand there's considerable time and expense on your behalf spent developing each plugin. Perhaps you could document the protocol required to communicate with your software 'backend'? (The MiniDSP.exe) Then people could develop their own firmwares without you needing to share any licensed software. I'm sure the DIY community would take over support for this aspect, as quite naturally it would not be in your interests to do that.
Thanks
🙂
Thanks, I stumbled on those at some point after posting. 🙂
miniDSP,
I apologise, I'm not coming at this from a 'for profit' motive if that's what you're suggesting. It's a fairly natural thing for DIYers to want to maximise the potential of a piece of hardware. Since starting this thread I have purchased 2 miniDSP boards, instead of the 1 I would require if the plugins were more flexible.
I understand there's considerable time and expense on your behalf spent developing each plugin. Perhaps you could document the protocol required to communicate with your software 'backend'? (The MiniDSP.exe) Then people could develop their own firmwares without you needing to share any licensed software. I'm sure the DIY community would take over support for this aspect, as quite naturally it would not be in your interests to do that.
Thanks
🙂
@ fb,
Thanks for the clarification and point well taken. 🙂
More flexibility and ability of programming is indeed something users want. Reality is only a small percentage of our users would be able to handle the complexity of programming the board. If you look at the majority of our users, they enjoy the plug & play and not having to worry about coding an application to make their audio up and running. That's what we've been focusing on so far.
This being said, your query is very valid and we're always happy to see how we could make this platform even more versatile. One way could be to open an API as you suggested. However, the problem of support is not as simple as you suggest I'm afraid.. 🙂 From the point on we open the API, we'll get a HOST of questions which will add to the already large amount of questions we're getting for basic DSP concepts... We do know that from experience and knowledge of this side of the business (e.g. friends having worked for DSP manufacturers). That's the reason why we would take things carefully into consideration. Although looking the same in terms of hardware, a dev platform VS a finished product are indeed two different beasts...
Hope this explanation makes sense, you can get in touch with us (by email) if you want to share some more ideas).
Thanks for the clarification and point well taken. 🙂
More flexibility and ability of programming is indeed something users want. Reality is only a small percentage of our users would be able to handle the complexity of programming the board. If you look at the majority of our users, they enjoy the plug & play and not having to worry about coding an application to make their audio up and running. That's what we've been focusing on so far.
This being said, your query is very valid and we're always happy to see how we could make this platform even more versatile. One way could be to open an API as you suggested. However, the problem of support is not as simple as you suggest I'm afraid.. 🙂 From the point on we open the API, we'll get a HOST of questions which will add to the already large amount of questions we're getting for basic DSP concepts... We do know that from experience and knowledge of this side of the business (e.g. friends having worked for DSP manufacturers). That's the reason why we would take things carefully into consideration. Although looking the same in terms of hardware, a dev platform VS a finished product are indeed two different beasts...
Hope this explanation makes sense, you can get in touch with us (by email) if you want to share some more ideas).
- Status
- Not open for further replies.