Hi, I was toying around with the Wolfson DAC chip on my dev board. But the results are there but seem sub optimal "running a sawtooth through there". While the simulation looks alright to the untrained eye. I know about aliassing and stuff but this seems to do a lot of it..
Astudentofminewhowasalittlepiggie wrote: > But the results are there but seem sub optimal "running a sawtooth > through there". What do you want to get out of what with what and whats the problem with this? > While the simulation looks alright to the untrained eye. What can be seen there? Does it help to understand the problem?
At low frequencies it sounds very good, but it breaks up faster than im used to DAC's doing. Eventually im planning on running it from a dedicated crystal osc. and not the 50 MHz, @ 78,125 KHz it is now. Basically im trying to justify why it starts sounding wrong "beating" at around 1 KHz. (and the oscillator driving it is alowed to overshoot) Thought maybe the timing of the data also is not quite right. Or treating it wrong in another way maybe?
Astudentofminewhowasalittlepiggie wrote: > it starts sounding wrong What says the oscilloscope?
Just moved to another OS.. It looks lik it has some kind of digital lowpass filter going. While im throwing an unsigned integer at it. at half of 1677216. The satturation maybe either my soundcard's preamp or the dac chip, it's the good kind at least :)
needless to say it sounds horrid..
As is my typing btw, I ment to say 16777216.
Any thoughts would be very much appreciated.
What do we see in the screenshots? And: what should be there instead? Just look at your posts like you would know nothing about your problem. Thats the way all of us have to look at it. We don't know the FPGA, the toolchain, the board, the DAC, and finally not to much about the problem itself...
: Edited by Moderator
It doesn't look to bad almost like its trying to do right. But maybe somewhere between the numbers im throwing at it and the frequency it's running on.. At least I hope my first timers problems may seem obvious to some people here. In general it does some mad aliassing.
Astudentofminewhowasalittlepiggie wrote: > At least I hope my first timers problems may seem obvious to some people > here. Due to you not answering any of my questions or adding a little snippet of information: HOW do you think may anybody be ABLE to help you? Its not, that no one wants to help you. Its just: nobody can. > In general it does some mad aliassing. Where can this be seen? What do we see, and what should be there instead? > I hope Hope is the only thing to lead you anywhere at that point... You know, there are 2 kind of people in the world: 1. those able to extrapolate from insufficient information.
: Edited by Moderator
Oh sorry, I was unaware you felt like there was too little info. What you are seeing in the pictures is a sawtooth generated from a counter. Which is producing a sample per sample. It is fed throug a medium end studio soundcard and it's class a preamp. So there are artifacts seen that should or could be expected. The counter in the picture was in between unsigned integers 4194304 - 12582912. @ 78,125 KHz <-- so those aspects in the build are a mayor void in my understanding of what is right, or if it's causing trouble in my dev board prototype. I did some audio programming in my life, so it's astablished to be "mad alissing" by ear. :) But compared to the every day results im used to it a bit worse. As im typing I get the suspicion it may be due to my counter still.. So ill log out and in another os to get the file posted..
module TinyRampForLEDs ( input clk, input [7:0] sync, input [15:0] pitch, output reg signed [23:0] cnt ); reg buffer; always @ (posedge clk) if(cnt>=8389108) begin cnt <= cnt- 1000; end else if (sync  > buffer) // sync  here is the same as sample clock in the simulation file begin cnt <= cnt+ (100 * pitch); buffer <= sync ; end else if (sync  < buffer) begin buffer <= sync ; end endmodule Also the input of the dac is sample and hold driven so there should be no issues with the data being mis aligned.. Basically this could case no issues i'd say..
At it for a bit. " reading on i did see it's digitally filtered in four modes that can't be turned off or not that i see before i am going to split :( " So.. Since im not simply going to get a hold of the "mode pin". The default setting is set to "10: I2S Format MSB-First left -1 justified" What does this say with the -1 there?