firmware regression?

[Ti Kan]

Hi all,

I was testing a firmware that I built on 3 December 2016
from the experimental branch, and I observed the following
problems:

Using an iPhone 6s as the digital source via the Apple
USB camera connection kit (basically a USB-to-lightning adapter
cable), the playback always starts up ok, but after a while
(may a track or two later) the audio sometimes derteriorate into
a garbled mess while the red/green rate feedback LEDs would
start flickering continuously. Occasionally the red and green
LEDs would also light up solid simultaneously while nothing
is obviously wrong with the audio.

Not sure if it matters, but the source material I was testing
with are 24/88 and 24/96 FLAC files. These files play fine
over my digital audio streamer system in S/PDIF format.

I don't experience these problems while running a firmware
I built on 26 August 2015, also from the experimental branch.

A lot has changed between the two dates. Borge, do you have
any idea where this problem might be? Do you recall any changes
that you had pushed that might affect this behavior?

-Ti

[Ti Kan]

I should add that when the audio starts sounding garbled,
resetting the widget or re-plugging the USB cable will
fix the problem (until it happens again). Simply stopping
and restarting playback, or changing tracks does not fix
the problem.

-Ti

--
Sent from Main Mission

[Ti Kan]

Another bit of info.

I have not experienced the problem after changing from using the
iPhone as source to a Windows 7 PC. I did not yet test Linux,
but it would appear to be an iPhone-specific problem.
These are all run in UAC2 mode.

I need to re-flash the widget to the older firmware to see
if I could reproduce the peoblem. But I have used
this combo before (iPhone + widget with old firmware) and
never run into this.

-Ti

[Børge Strand-Bergesen]

Hi Ti,

I'm pretty sure what you're experiencing from Dec 3 is my attempt at making buffer address read operations fully atomic. This is something I put in so that reading which half-buffer we're using AND the local address within the half-buffer in question happens without one of the two changing. Back then I don't remember testing with iPhone. It may also be that an iOS update has done something to things. But in any case, I decided to redo the atomic stuff.

Half-buffer and address read mismatches do happen, although rarely. But when it does the gap calculation is quite off. And as a principle it is good to read the two parts of what is essentially the same global buffer address, at the same time.

My first attempt was to disable global interrupts around the variable read moments. That didn't work too well. I believe that's what you're seeing. In the commit history I did try to replace this with RTOS macros, before I did away with atomic operations altogether.

The code now reads the half-buffer number into DAC_buf_DMA_read_local, then reads num_remaining, and finally validates the pair by checking if DAC_buf_DMA_read_local is still equal to DAC_buf_DMA_read. If the 1st and 2nd read operation match up, the in-between read of num_remaining is correct, and the gap is calculated. If the 1st and 2nd read are different, old_gap is used instead, and the state machine is instructed to do another read soon.

That version is in there, and I pushed it again today for good measure. Could you please have a look at Makefile and check if your product definition makes sense? I added your definition to the comments.

A better version is perhaps to simply read num_remaining again if the initial DAC_buf_DMA_read mismatch. But before I do that, please build from source and re-test.

These days I'm toying with SPDIF buffering code on some unique hardware. Let me know if you want to add any SPDIF RX anytime soon. I have the WM8805 up and running and its I2S output passing through the MCU. It's functional but not yet pretty in any way.

Børge

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.
To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ti Kan]

Hi Borge,

Thanks for the reply. I reverted back to the old August 2015 firmware
and it does not exhibit the problem with the iPhone. So the issue
was definitely introduced sometime after that date and before
3 December 2016.

One different problem I discovered, though, is with the Windows 7 PC
running foobar2000, playing music continuously on repeat. Eventually
the playback would stop at the start of a track. But clicking play
again would not restart the playback, nor would double clicking on
another track. No errors are shown on the screen, and the widget's
rate feedback LEDs are both off. Replugging the USB cable usually
fixes this playback is possible again. This occurred on both the
August 2015 and December 2016 firmware. I don't know whether this
is a foobar2000 issue, or something downstream.

Anyway, I will build from the currently pushed code and retest
with the iPhone, Windows PC and Linux PC later tonight.

-Ti

> > email to audio-widget...@googlegroups.com.

> > For more options, visit https://groups.google.com/d/optout.
> >
>

> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[Ti Kan]

I started from scratch, pulled in the current experimental branch
and built a new firmware. I tested it with the iPhone and
I did not experience the problem. Well, at least for about
2-3 hours until my USB-to-lightning adapter seems to have failed.
Now the iPhone cannot be used on any of my audio widgets, regardless
of firmware version.

I am currently testing with Windows 7 and Linux PCs and so far
nothing bad has happened yet. I'm letting them both run continuously
and will report back later.

PS. I forgot to answer your question about SPDIF stuff.
I currently have no plan to use the widget for that. It may
change in the future, but as of now I'm using it strictly for
USB-I2S. I am still very interested in DSD (DoP) support...
There was a small flurry of discussions about this last year
but nothing happened.

-Ti

[Børge Strand-Bergesen]

Hi Ti,

Sorry, this got lengthy (again)...

Keep me posted on the test status. I have sunk $100 into camera adapters, they float all around the place where I live/lab.

In my experience, what you saw on long-term testing with Win7 is rare. Now and then I run burn-ins on manufactured units. They can run for days on end. Then I typically have two DACs on one computer, one in f2k and UAC1, the other on JRiver, ASIO and UAC2.

The buffer+address co-verification code is still not 100% mature. Experience from SPDIF buffering will probably filter into that code even for USB.

DSD support is very cool. I haven't been able to make any progress on that, other than writing a todo list and verifying that there is nothing wrong with the ambition level :-)

- Download some .dsf or .dff content, I didn't quite understand how the individual bits are indexed in the format spec...

- Get it into and out of Octave by modding wavread() and wavwrite() for quick prototyping

- Experiment with a player which dumps the content natively into the AW over USB.

- On today's hardware do some simple bit-count-look-up to verify and play back 4-bit audio or similar on the AK4430 over PCM

- Add hardware first for DoP, then synchronous interface. May require code magic and/or CPLD

- In the Octave domain, ask some students to simulate DSD->PCM conversion for playback on 176.4 with today's hardware

- Port converter to firmware

SPDIF buffering is something I have started on but not finished. I'd like to get further there before starting on new IO:

- Basic functionality over I2S in and out. OK

- Basic buffering in MCU at all sample rates. OK

- Detection of SPDIF vs. XO drift. Sketched on paper

- Rough sample skip/insert. Sketched on paper

- Refined sample skip/insert at least audible spot, Simulink sim. Two students working on it with me.

Now while we're at it, let's talk about MQA. I'd love to support it. But code is closed. I don't know how math intensive it is either.

- Don't feel like swapping MCUs, even though the AVR32 is getting old and expensive

- Don't feel like blending closed and open source unless we can do it elegantly and ethically (like with the asio .h file)

- Don't feel like having to add an MQA co-processor in hardware

- Trying to figure out how MQA can reside in ASIO driver or player software. IMHO PC's CPU is the best place to run it. Not sure MQA guys agree.....

Cheers,

Børge

> > > email to audio-widget+unsubscribe@googlegroups.com.

> > > For more options, visit https://groups.google.com/d/optout.
> > >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> > To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

> > For more options, visit https://groups.google.com/d/optout.
>
> --
> Sent from Main Mission
>
> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
Sent from Main Mission

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Ti Kan]

Hi Borge,

I am going to get a replacement iPhone Lightning USB Camera Adapter
tomorrow and test some more. As for Windows and Linux, the tests
are still running with no apparent problems. Yay!

As for DSD, seems like you're going about it the hard way. I don't
think we need to do "native DSD", so there is no need to understand
the format of .dsf or .dff files. DoP (DSD over PCM) hides a lot of that
from us, and there is no DSD/PCM conversion anywhere, and no loss
of quality occurs.

Have you looked at the DoP specifications (it's very short. so won't take
long to read):

http://dsd-guide.com/dop-open-standard

Basically, it's the following:

1. The player software (such as foobar2000 or jriver) interprets the
DSD file and its data (via a plugin) wraps DSD data (with an 8-bit
special marker and 16 bits of data) into 24-bit PCM-like packets
and sends them down to the transport. Left and right channel
data are carried in separate interleaving packets. Single-rate
DSD (DSD64) is carried by PCM packets at 176.4KHz sampling rate.
(See the specifications about how double rate DSD128 or higher are
handled).
2. As far as audio drivers, USB audio hardware, etc., they don't know
that the stream is DSD. It looks like regular PCM to them.
3. On the receiver side (in our case, the audio widget), the firmware
needs to snoop the data in the input buffer (by looking for the
special markers) to detect whether the data is DSD wrapped in PCM rather
than real PCM.
4. If it is DSD, then the firmware takes 16-bit payload data from
the PCM packet and sent out via three lines (DSD-L, DSD-R and DSD-clock)
while flagging that this is a DSD stream by setting one of the GPIO pins
to cause some external logic on the analog board to route the above
to the appropriate pins on the DAC and set it to DSD mode.
5. That's pretty much it!

If possible, the DSD-L, DSD-R and DSD-clock signals can ride on the
same wires as the I2S lines used when in PCM mode. A very common
(but not universal) mapping on DACs is:
DSD_L -> LRCLK
DSD_R -> SDATA
DSD_clock -> SCLK
If the DAC isn't mapped this way, some routing logic can take care
of the differences.

As I posted before, I don't know if it's possible to make this mapping
on the audio widget. That's something need exploring but it's beyond my
knowledge as far as the AT32UC is concerned. Also I don't know the
code enough to know where to code the snooping of the special DSD markers
in the input buffer.

With the current widget implementation (max 192KHz PCM sampling rate),
we could support up to DSD128 (using method two with 176.4KHz, see
specifications). If Jaroslav's 384KHz sample rate support is stable
and incorporated into the main code, then we could support up to DSD256
(method 2 with 352.8KHz sample rate).

As for MQA, the closed aspect of it runs contrary to the open source
nature of audio widget, and that is enough to be a big red NO flag
for me. As far as I can tell, it doesn't offer anything over what's
already out there in PCM or DSD land, except it tries to get the recording
industry into the loop. I think it's more about getting large corporate
players to sign on and pay big royalty money, and less about sound
quality.

HDMI is also a closed system, and that's why you don't see any open
source or DIY project using it.

-Ti

On Fri, Feb 10, 2017 at 11:46:51AM +0100, Børge Strand-Bergesen wrote:
> Hi Ti,
>

[Børge Strand-Bergesen]

Ti,

I want to run DSD on today's hardware! That means DIY DSD-PCM conversion. I'm curious if it will work. Hence the need for understanding and analysis.

But I guess I'm over-complicating things (again).

I'll read all of your mail over the next few hours. Now I'm off.

Have a great weekend!

Børge

[Ti Kan]

Borge,

Yes, what I described is on today's hardware. The only proposed changes
are in firmware. If we do it right no changes are necessary on the
widget module itself. Only some extra logic to route the signals to the
appropriate pins to the DACs, and to switch the DAC's operating mode.

-Ti

> > email to audio-widget...@googlegroups.com.

> > For more options, visit https://groups.google.com/d/optout.
> >
>

> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[Børge Strand-Bergesen]

On today's module DSD over PCM should be very doable. But today's AK4430 needs conversion in player or fw. And the AK4490 I'm designing in these days uses two data pins. DoP chips limits the choice a lot. But DoP is still a good starting place!

Børge

[Ti Kan]

Hi Borge,

The AK4430 is a PCM-only DAC, it does not support DSD audio. Thus it
requires DSD-PCM conversion. But rather than do it in the audio widget,
players such as foobar2000 already have plugins that could do this
on the fly. So on such DACs, just let the software do it.

All DACs that support DSD have two data pins, one for left channel
and one for right channel. In addition, there is a DSD clock pin.
These are what I referred to as DSD_L, DSD_R and DSD_clock in my
previous emails. Many DACs use the same pins as some of the
I2S pins, depending on the mode (DSD or I2S/PCM) it's operating in.
For example, on the AK4490, pin 3 is the SCLK input in I2S/PCM mode
but becomes DSD_clock in DSD mode. Pin 4 is SDATA in I2S/PCM mode
but becomes DSD_L in DSD mode, while pin 5 is LRCLK in I2S/PCM mode
but becomes DSD_R in DSD mode. Note though, the AK4490 can be set
to DSD mode only when running in software controlled mode.

P.S. My Windows and Linux PC testing ran for 24+ hours with no issues.
Re-running now with iPhone (and a new USB camera adapter).

-Ti

On Sat, Feb 11, 2017 at 01:23:46AM +0100, Børge Strand-Bergesen wrote:
> On today's module DSD over PCM should be very doable. But today's AK4430
> needs conversion in player or fw. And the AK4490 I'm designing in these
> days uses two data pins. DoP chips limits the choice a lot. But DoP is
> still a good starting place!
>
> Børge
>
> On Friday, February 10, 2017, Ti Kan <t...@amb.org> wrote:
>
> > Borge,
> >
> > Yes, what I described is on today's hardware. The only proposed changes
> > are in firmware. If we do it right no changes are necessary on the
> > widget module itself. Only some extra logic to route the signals to the
> > appropriate pins to the DACs, and to switch the DAC's operating mode.
> >
> > -Ti
> >
> > On Fri, Feb 10, 2017 at 02:54:31PM +0100, Børge Strand-Bergesen wrote:
> > > Ti,
> > >
> > > I want to run DSD on today's hardware! That means DIY DSD-PCM conversion.
> > > I'm curious if it will work. Hence the need for understanding and
> > analysis.
> > >
> > > But I guess I'm over-complicating things (again).
> > >
> > > I'll read all of your mail over the next few hours. Now I'm off.
> > >
> > > Have a great weekend!
> > >
> > > Børge
> > >
> > >

> > > On Fri, Feb 10, 2017 at 2:10 PM, Ti Kan <t...@amb.org <javascript:;>>

> > > > email to audio-widget...@googlegroups.com <javascript:;>.

> > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > Groups "Audio-Widget" group.
> > > To unsubscribe from this group and stop receiving emails from it, send

> > an email to audio-widget...@googlegroups.com <javascript:;>.

> > > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > Sent from Main Mission
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Audio-Widget" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to audio-widget...@googlegroups.com <javascript:;>.

[Ti Kan]

Hi Borge,

Unfortunately, the iPhone ran for a few hours and the problem
occurred again, with the current experimental branch firmware.

To recap the problem, the audio turns garbled and slows down in
speed, and both rate feedback LEDs flicker back and forth
in quick succession. Re-plugging the USB cable restores the
playback to normal again.

-Ti

[Børge Strand-Bergesen]

Yes,

I know the AK4430 can't and the AK4490 can, at least on special pins. Maybe we can use MCU hardware to support DSD pinning. That would be cool. Or maybe there has to be some external logic.

As for the AK4430, there is a reasonable install base out there and it'd be fun to make it handle DSD. But this isn't a big issue.

I have an AK4490 design in the works. It will be SW controlled. Let me know if you'd like to see the temporary sch files.

Børge

> > > > email to audio-widget+unsubscribe@googlegroups.com <javascript:;>.

> > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > Groups "Audio-Widget" group.
> > > To unsubscribe from this group and stop receiving emails from it, send

> > an email to audio-widget+unsubscribe@googlegroups.com <javascript:;>.

> > > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > Sent from Main Mission
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Audio-Widget" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to audio-widget+unsubscribe@googlegroups.com <javascript:;>.

> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Jaroslav Dohnal]

Hi guys.

About MQA, I worked with it...forget it. There is absolutely no way you can support it, it needs way more power than our poor old AVR32 can deliver. And its all strictly closed. 

About DSD, are you actually thinking doing DSD decimation filters on this AVR32? First, it completly kills the point of DSD that it doesnt have any digital filters in the way (which fuckup impulse response, most important factor of digital audio) and second any PC SW (say foobar) can do it way better. Also, I doubt you would have enough power for detecting, formating DoP and then doing any decimation filters. 

You will have to use AK4490 hardware or something similar supporting DSD intput. That can probably work on two SPI modules running in slave mode with CS grounded. Let me know if you want some schematics and stuff. Way back I planned AVR32 + AK4490 DAC and I have all the files in altium. I can put that open if someone wants. I also have SW libraries for AK4490, they don't acces all the functions, but they do all the important to support DSD, PCM, volume and so on...

> > > > email to audio-widget...@googlegroups.com <javascript:;>.

> > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > Groups "Audio-Widget" group.
> > > To unsubscribe from this group and stop receiving emails from it, send

> > an email to audio-widget...@googlegroups.com <javascript:;>.

> > > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > Sent from Main Mission
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Audio-Widget" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to audio-widget...@googlegroups.com <javascript:;>.

> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

[Børge Strand-Bergesen]

Hi Jaroslav,

I'd certainly like to know your input on using the AK4490.

I've been diving pretty deep into the pdca code recently in my attempts to use the MCU as an I2S buffer between two almost-identical clock domains. Progress has been good on receive, buffer and playback. Creative sample skip/insert will come next.

With the knowledge from the pdca code (AVR32108 text) I believe DSD can be sent out to something like the AK4490. It will require the L and R data to be split into separate buffers and played back on two separate, fully synchronous parallel-to-serial converters. When that is in place, output clocking must also be modified from I2S to DSD.

I'd like to work on the synchronous L and R PISO code first. Such a mechanism can also be used to send +-L on one I2S and +-R on another. That is very neat for a split L/R analog setup. Quite doable in CPLD or similar, but why add hardware if we can avoid it.

Alex (et al.)

For years I've tried to understand why the sequential code is writing to -the-same- buffer as the DMA is set up to read from. By reading the pdca text from Atmel it is now evident to me that pdca_reload_channel() sets up the -next- pointer of the pdca, not the one to use currently and immediately. And it is the contents of that -next- buffer which is being generated by the seq code while the DMA is outputting the contents of the -current- buffer, the selection of which was done automatically, because it was set as the -next- buffer on the previous interrupt.

Both DSD and MQA in firmware were ideas I was toying with to try to make the existing hardware compatible with other formats. But the hassle probably isn't worth it. I know the AVR32 is getting old compared to the new stuff which keeps coming out. I just love the idea of a generic MCU over a dedicated USB Audio controller.

Børge

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Ti Kan]

For what it's worth, here is a critical article about MQA.  Coming from Linn, it's not a surprise, but they do bring up many valid points.

https://www.linn.co.uk/blog/mqa-is-bad-for-music

Technical issues aside, MQA is surely not friendly to the open source or DIY communities, and it flies in the face of projects like audio widget.

As for DSD, I agree with Jaroslav. The only two viable solutions for us is:

1. Keep things as is, let the foobar2000 (or other player) plugin do the work of converting DSD to PCM.  But the DSD purists won't like any such conversion.

2. Do DoP in the audio widget and then let the DAC hardware handle the DSD streams.  Of course this requires DSD-capable DACs, but most modern DACs do these days.

-Ti
-- 

Sent from my commlock

[Børge Strand-Bergesen]

Hi Ti,

I'd like to bring DSD capability into the Audio Widget project. Not just for chips which accept DSD data as I2S packages, but for the AK4490 style DSD input as well.

My initial thought was to have two separate, PDCA driven, parallel in - serial out units for L and R DSD. When I look at the datasheet I find only one SSC, Synchronous Serial Controller. In the code, PDCA_OPTIONS and SPK_PDCA_OPTIONS refer to the RX and TX SSC ports, respectively.

Do you think DSD with two data lines can be done with any other kind of hardware? Perhaps we could re-purpose a pair of USARTs? What do you think? I haven't worked deeply enough in the IO hardware to tell for sure.

Jaroslav, how far did you come in terms of DSD support?

Børge

[Ti Kan]

On Sat, Feb 25, 2017 at 06:30:19PM +0100, Børge Strand-Bergesen wrote:
> I'd like to bring DSD capability into the Audio Widget project. Not just
> for chips which accept DSD data as I2S packages, but for the AK4490 style
> DSD input as well.

Wait a minute... what DAC accepts DSD data as I2S packages? I haven't seen
any.

All the DSD-capable DACs have separate raw DSD L and R inputs as well
as a clock pin. These may be "double duty" pins (i.e., same pins
as I2S), but accept normal I2S data in PCM mode only. When switched
to DSD mode, those pins accept DSD inputs. The AK4490 is one of these.
It's pin 3 is I2S bit clock in PCM mode, but becomes DSD clock in
DSD mode. Pin 4 is I2S data in PCM mode, and DSD left channel input
in DSD mode. Pin 5 is word clock in I2S mode, DSD right channel input
in DSD mode. A mode change can only be done on the AK4490 in software
(set or clear the DP bit in control register address 0x02, followed by
a reset. (RSTN)

Other DSD-capable chips are similar, like Cirrus CS4398, Wolfson WM8741,
Asahi Kasei AK4399 and later, and Texas Instruments PCM1792 and others.
Analog AD1955 has separate pins for PCM and DSD. These are all, in your
words, "AK4490 style". And it is the only style we're concerned about.

> My initial thought was to have two separate, PDCA driven, parallel in -
> serial out units for L and R DSD. When I look at the datasheet I find only
> one SSC, Synchronous Serial Controller. In the code, PDCA_OPTIONS and
> SPK_PDCA_OPTIONS refer to the RX and TX SSC ports, respectively.
>
> Do you think DSD with two data lines can be done with any other kind of
> hardware? Perhaps we could re-purpose a pair of USARTs? What do you think?
> I haven't worked deeply enough in the IO hardware to tell for sure.

I don't know enough about the Atmel chip to answer this, but for
"other kind of hardware", are you talking about something other than
the Atmel? Or are you talking about something external?

> Jaroslav, how far did you come in terms of DSD support?

Yes, I would like to know this too.

-Ti

Sent from Main Mission

[Børge Strand-Bergesen]

On Sat, Feb 25, 2017 at 8:02 PM, Ti Kan <t...@amb.org> wrote:

On Sat, Feb 25, 2017 at 06:30:19PM +0100, Børge Strand-Bergesen wrote:
> I'd like to bring DSD capability into the Audio Widget project. Not just
> for chips which accept DSD data as I2S packages, but for the AK4490 style
> DSD input as well.

Wait a minute... what DAC accepts DSD data as I2S packages?  I haven't seen
any.

 

They exist. But they also accept AK4490 style DSD, so let's have that as a target. Sorry, not allowed to go into details.

 

> My initial thought was to have two separate, PDCA driven, parallel in -
> serial out units for L and R DSD. When I look at the datasheet I find only
> one SSC, Synchronous Serial Controller. In the code, PDCA_OPTIONS and
> SPK_PDCA_OPTIONS refer to the RX and TX SSC ports, respectively.
>
> Do you think DSD with two data lines can be done with any other kind of
> hardware? Perhaps we could re-purpose a pair of USARTs? What do you think?
> I haven't worked deeply enough in the IO hardware to tell for sure.

I don't know enough about the Atmel chip to answer this, but for
"other kind of hardware", are you talking about something other than
the Atmel?  Or are you talking about something external?

I hope we can re-purpose some Atmel ports and use PDCAs. Gotta study the USARTs (or similar ports) more in detail. 

 

> Jaroslav, how far did you come in terms of DSD support?

Yes, I would like to know this too.

Børge

 

-Ti

> >> email to audio-widget+unsubscribe@googlegroups.com.

> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Audio-Widget" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to audio-widget+unsubscribe@googlegroups.com.

> > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Audio-Widget" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to audio-widget+unsubscribe@googlegroups.com.

> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
Sent from Main Mission

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.