asic_designer

Members
  • Posts

    12
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

asic_designer's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Hi In all honesty I can't tell the difference. My girlfriend had been listening to me trying different fixes for this DAC issue for almost 3 or 4 days, and once I applied the fix, and she heard the music, she asked me, "so you gave up on trying to fix your circuit problem, I see you went back to playing music through your iPad." LMAO, she didn't even realize that I was playing the music through the FPGA. I still haven't told her LOL. So you might be able to tell the difference using an oscilloscope, but I can't hear the difference, its sounds great to me, and my girlfriend!
  2. Yes that was my thought so I asked but for some reason he was insistent on this point.
  3. OK soooo, I found the problem, the solution was ~mentioned here but it got by me, so here is the explanation I got from a DSP guy just to be clear. "You shouldn't be complementing, you should be offsetting all the samples by adding 32768 before feeding your DAC. This way the zero signal output will be half rail and the audio can swing both ways. I have not looked closely at the code, Verilog is not my thing." Explanation ---> Well your input range is -32768 -> 32767 correct? Your DAC expects to see 0 -> 65535, the addition of 32768 to your signed value (note +32768 needs 17 bits as a signed integer) will yield a value having a range of 0 -> 65535 (17 bits as a signed value) which you then convert to unsigned (16 bits), with audio silence being somewhere in the middle of that range. Audio DACs all have an output corresponding to zero (audio sample value) input of mid scale, you then remove the DC component with a series cap. If you think about it the process MUST be linear (anything else introduces mixing products), which addition is, but complement only some of the time most certainly is not. If +1 produces output 20 & zero produces output 15 then -1 should surely produce output 10, not go back up to output 20, generally anytime you find yourself doing different things depending on the sign of a sample you are introducing a non linear element and that is usually not what you want. Addition not xor!
  4. So I the cranked up the clock frequency to 300Mhz, and I took absolute value of the input to the DAC ( in other words I took the twos complement of all negative numbers in the input stream). This did create a dramatic difference in the sound, it is better no doubt about it, but the voices in the music are still bad, the melody it self is much improved but the voices are still robot like, with lots of static. I'm going to check the PCM input to see if there is a dependency between what is being sent and what I am getting.
  5. I get the feeling now that this might be the issue Jaxartes mentioned this as well and looking at the verilog code for this DAC, I'm pretty sure it was meant for unsigned numbers and I'm fairly certain that the data coming across the I2S interface is 16 bit twos complement data. So yes there is a discrepancy here, that has to be corrected. I'll have to update the verilog code. Thanks! `timescale 100 ps / 10 ps//`define MSBI 15 // Most Significant Bit of DAC input// This is a Delta-Sigma Digital to Analog Convertermodule delta_segma_dac#(parameter MSBI = 15)( input wire CLK, input wire RST, input wire DAC_EN, input wire [MSBI:0] DAC_IN, output wire DAC_OUT ); //**********************************************************//==========================================================// variable, constant, and wire declarations//==========================================================//**********************************************************//==========================================================// constant declaration//========================================================== //==========================================================// wire declaration//==========================================================wire [MSBI+2:0] DeltaB; // B input of Delta adderwire [MSBI+2:0] DeltaAdder; // output of Delta adderwire [MSBI+2:0] SigmaAdder; // output of Sigma adder //==========================================================//variable declaration -- they are not REGISTERS !!!!!!!!!!//==========================================================reg DACout;reg [MSBI+2:0] SigmaLatch; // Latches output of Sigma adder//==========================================================// HARDWARE IMPLEMENTATION CODE//==========================================================assign DeltaB = { SigmaLatch[MSBI+2], SigmaLatch[MSBI+2], {MSBI+1{1'b0}} }; assign DeltaAdder = DAC_IN + DeltaB;assign SigmaAdder = DeltaAdder + SigmaLatch;always @(posedge CLK or posedge RST)begin if ( RST == 1'b1 ) begin SigmaLatch <= 1'b1 << (MSBI+1); DACout <= 1'b0; end else begin if ( DAC_EN == 1'b1 ) begin SigmaLatch <= SigmaAdder; DACout <= SigmaLatch[MSBI+2]; end endendassign DAC_OUT = DACout;endmodule
  6. Thanks for the suggestion, however this design is for a completely different SoC and I'm pretty sure that the error must be on my part, (well since I designed the SoC). BTW I have the wave player project, and I will use it to compare data and see if there are discrepancies, thanks!
  7. Thanks for you input, and the explanation. I'm putting some of these suggestions to use now. I'll have an update in a little while for you guys.
  8. OK I changed the clock rate to 300Mhz and it still sounds the same, horrible. So can you describe the data flow you used in your projects? A. Were the DACs constantly enabled (constantly summing) and you just simply feed them the new data as it came into the block? If so, did you insert zeros in between samples or just leave the last sample there while the DAC continued to sum until new data came in? B. Were the DACS only enabled for a single clock cycle at the sample rate on the arrival of new data? C. None of the above? BTW, thanks for your help so far!
  9. BTW I saw that app note, for 16 bits it suggests a frequency of 4.9Ghz or something like that. It then goes on to say that that high frequency is not necessary that a much lower frequency can be used. The formula will produce a outrageously high frequency so I can't use that.
  10. . OK so you are saying I don't need the filter, just simply up the clock frequency to about 300Mhz? OK do I have to insert zeros in between samples, or simple enable the dac for a single clock cycle when a new sample arrives?
  11. The board I have already has an audio jack, so the filter that I need is an embedded one, not an additional external jack. I really can't use that in my current application. Thanks for letting me know about it though. Here is my question, how did the "wave project" ever work without this embedded filter? Was the filter implemented in software or something? Any one know where I can get one? An interpolation filter for this type of application?
  12. Hello Everyone Has anyone here every tried this successfully? I'm trying to stream CD quality audio through an I2S interface directly to a Delta Sigma DAC, and out to the headphone jack. I can hear the audio through the head phones connected to the jack on the board but the audio sounds HORRIBLE. I've been told that I need to implement an interpolation filter in between the delta sigma dac and the I2S receiver and that I can't send the audio directly to the DAC? I noticed that there was a wave file project given away with the Pipistrello board, so I'm assuming that someone has tried this and gotten it to work? So here is my set up FPGA: Spartan 6 lx45 Pipistrello board External Bluetooth Chip Connected via an I2S interface CD Quality Audio Streaming at 44.1kHz 24bit data cropped to 16 bits ( LSB cropped ) 16bit data feed to the Delta Sigma DAC running at 75Mhz So, I need an interpolation filter, or so I'm told, so do we have any laying around here? Any other suggestions or solutions to this problem? Thanks in advance for all of your help.