Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 34 of 34

Thread: Ethernet audio library ready to beta test

  1. #26
    Junior Member
    Join Date
    Mar 2020
    Posts
    16
    More data..

    I have narrowed the issue down to these two lines in control_sgtl5000.cpp enable()

    Code:
    	write(CHIP_ANA_POWER, 0x40FF); // power up: lineout, hp, adc, dac					// fixed "broken" teensy by downloading, but didnt survive reboot
    	write(CHIP_DIG_POWER, 0x0073); // power up all digital stuff						// fixed reboot issue with previous line
    I'm reasonably sure if you can run these two lines in control_ethernet::enable(), then the issue will be resolved. I feel like there should be a way to do this with inheritance but I just don't know enough about the structure of the classes.

    I see that AudioControlSGTL5000 extends AudioControl. So I thougth I could just replace AudioControl with AudioControlSGTL5000 in control_ethernet but it didn't quite work the way I was expecting...

    I'll leave the fix up to smarter people than I.

  2. #27
    Senior Member
    Join Date
    Aug 2016
    Location
    Australia
    Posts
    101
    Thanks for the diagnostic, it's good to know exactly where the pain is. It doesn't immediately indicate what the issue is, unless these are the first write register commands in SGTL...enable().

    Your proposed solution isn't the best way to approach the issue. BTW each of the two child classes inherits AucioControl in a different way, so Ether inheriting SGTL isn't going to be a good idea. It also ties SGTL and Ethernet together, which is not appropriate (i.e. they should be able to be used independently).

    I'll dig a bit more. I have a suspicion that all the pins are somehow being messed up while they are being sorted out: SGTL - clocks, TX/RX, enable and I2C and Ether - SPI, enable.

  3. #28
    Junior Member
    Join Date
    Mar 2020
    Posts
    16
    It also ties SGTL and Ethernet together, which is not appropriate (i.e. they should be able to be used independently).
    Oh. Hmm. I hadn't thought of that. I assumed I had to use one or the other. Kinda makes more sense now. lol. So now I see why trying to play with inheritance was moot.

    So If I wanted to use, say, a net in and and an I2S out the Audio shield, I would just have one AudioControlEtherNet control AND a AudioControlSGTL5000 control and then patch as necessary? Sometimes I wonder how I got this far in life.lol.

    I guess I'm confused because audio in and out the SGTL works using the AudioEthernet library.

    I would assume that all those things that get done in the AudioControlSGTL5000::enable() are probably important, and they won't get done if you don't create an AudioControlSGTL5000 instance. That's why I was confused how AudioControlSGTL5000 fits in...I didn't see how that library would do anything without instantiating an instance or inheriting it.

    In my testing I added an instance of AudioControlSGTL5000 (in addition to the AudioControlEtherNet instance) which fixed the issue. So I guess technically there really isn't an issue, I was just using it wrong.


    Thank you for all your help on this. I got audio coming in the Audio shield on one and out the Audio shield on the other and I'm very surprised and how low the latency is. Barely perceptible. Now lets see what happens when there are 8 streams.. well that will have to wait until I buy 6 more Teensys. If this all works out we'll be making 50+ of these...

  4. #29
    Senior Member
    Join Date
    Aug 2016
    Location
    Australia
    Posts
    101
    Every piece of hardware has a single Control object - so yes an AudioControlEtherNet control AND a AudioControlSGTL5000.

    Audio input and output for the SGTL is handled by input_i2s / output_i2s and input_net / output_net.

    In the Net case, as many input_net / output_net objects are created as necessary to talk to other hosts or multiply the number of channels (I'll create input_4net / output_4net sometime soon to handle quad traffic, 8 channels takes us over the 1500 byte ethernet MTU limit). So stack up a few objects and try it out.

    At 100Mbits, the theoretical max is limited by the SPI rate (you need to increase this to 30Mb/s in W5100.h if you haven't done so already, as there's lots of SPI chatting with the WIZ going on other than data transmission) and the max W5500 ethernet rate (15Mb/s) over a 100Mb/s link. This equates to about 16 channels each way, total. I've only tried 2+2 each way so far, and had zero dropouts on an isolated network.

  5. #30
    Junior Member
    Join Date
    Mar 2020
    Posts
    16
    I'll create input_4net / output_4net sometime soon to handle quad traffic
    Me being greedy... I'm only interested in mono streams. No idea what is involved with that. I would assume that would halve the bandwidth and reduce the processing power needed to process (?)


    For my situation, each unit will only generate one mono network stream, but may be subscribed to 1 or several (possibly up to 8 but normally 1-3) incoming (broadcast) streams.

    Also I see that it seems once an output stream is enabled, that it turns on the ethernet faucet. With broadcast traffic, I'm guessing this will increase workloads of all units on the network, even if they aren't subscribed (?) as they still need to see if that packet is for them. Or is this overhead small?

    Is there a possibility to not send packets if there is no audio? (Assuming it makes sense to do so)

  6. #31
    Senior Member
    Join Date
    Aug 2016
    Location
    Australia
    Posts
    101
    A small gain in processing power, and yes it nearly halves the bandwidth (each packet has an overhead).

    It's in my longer ToDo list - it is not difficult, but involves a lot of fiddly work, creating a pair of extra in/out objects and a new packet type to support them. When I do it, it will be something like the new multi channel I2S routines, with a common core of code and just the differentiated code in each specific file.

    In all, unless you're using a whole lot of the two channel objects (8 or more), you shouldn't get close to WIZ limits, and the T4 has an abundance of processing power, with audio buffer handling consuming a very small proportion of that.

  7. #32
    Senior Member
    Join Date
    Aug 2016
    Location
    Australia
    Posts
    101
    I'm having all kinds of pain running the Audio Shield with Ethernet at the moment (T4, rev D Audio Shield). Ethernet's working on its own with the AudioShield in place and un-enabled; as is the AudioShield with ethernet SPI connected but not enabled. As soon as I enable the AudioShield after the Ethernet, everything stops.

    Can you flick across your working code for your
    I got audio coming in the Audio shield on one and out the Audio shield on the other.
    Both libraries and sketch would be useful, so that I can see where I've introduced the error into the library?

    BTW, which Teensys are you using?

  8. #33
    Junior Member
    Join Date
    Mar 2020
    Posts
    16
    I'm away on business this week so I'm away from the hardware.

    I am using the 3.6 so not sure how much this will help, but I have two 4s and 2 more audioshields coming by the weekend.

    This is a long shot of a guess but I've found similar issues if I do not include this line in the setup, I don't understand why:
    Code:
    AudioConnection          patchCord(net_in1, 0, net_out1, 1);
    If I don't do this, the code stops before it gets even to the setup(). As soon as I add it, everything works normally even though I'm not using that output channel.

    Here's my working 2 way, the modified library, and my current pinout.
    2way test.zip

    One thing to note, this code relies on having a 2 or 3 written to address 0x00 in the EEPROM to determine the setup.

    Note, one additional (unrelated) change I made to the library is added a overloaded AudioPlaySerialflashRaw::lengthMillis(const char *filename) that allows you to get the length of a file without actually playing it first which is useful for scheduling a string of audio clips together.
    Last edited by turbo2ltr; 03-17-2020 at 09:24 AM.

  9. #34
    Senior Member
    Join Date
    Aug 2016
    Location
    Australia
    Posts
    101
    Thanks for the files and explanations.

    I'll dig through my code and yours and see if I can find the bug(s). It may not be the same thing causing both issues - despite them having similar symptoms (dying at setup() ).

    I've now tested the code on both a T3.2 / Rev C board and a T4 / Rev D board with the same fault appearing, so my guess is that the T3.6 will behave pretty much the same as the T3.2 in this case.

    No problems with your updated (and quite neat) way of storing the HostID and IP - it saves changing code for each chip programmed. I'll have a look at adding it to the code base, and maybe adding a simple Serial Monitor command parser to set the values remotely.

    BTW in V2 of the code, I'm pulling enable() out of the AudioControlEtherNet constructor, as it doesn't make sense to auto-run it before the SPI pins and IP/MAC are established.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •