| 00:05.45 | *** join/#edev Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 01:01.37 | *** join/#edev Belliash (~belliash@asiotec/constitutive/belliash) |
| 01:24.42 | *** join/#edev djerome (~djerome@ip68-2-20-108.ph.ph.cox.net) |
| 02:06.11 | *** join/#edev ntfreak_ (~ntfreak@unaffiliated/ntfreak) |
| 02:22.41 | *** join/#edev ffio (~fire@unaffiliated/security) |
| 03:08.40 | *** join/#edev [7] (~quassel@rockbox/developer/TheSeven) |
| 03:09.47 | *** join/#edev groglogic (~groglogic@65.100.175.151) |
| 03:10.16 | *** join/#edev g1powermac (~g1powerma@rrcs-74-87-150-6.west.biz.rr.com) |
| 03:10.19 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 05:01.50 | *** join/#edev landley_ (~landley@c-50-148-218-118.hsd1.mn.comcast.net) |
| 05:29.35 | *** join/#edev gkwhc (~gkwhc@unaffiliated/gkwhc) |
| 05:35.40 | gkwhc | Hi everyone, Im trying to implement a .wav audio player on a TI DSP (more specifically, im modifying a pre-existing mp3 player code). I just had a breakthrough of outputting sound that resembled the original music to the DAC. However, I am hearing frequent/regular pops in the audio, and the quality is very poor. What are the possible causes? I suspect its due to constantly filling buffers by reading from the SD card, but im not sure how to confirm. Any sugge |
| 05:47.21 | *** join/#edev mbuf (user@nat/redhat/x-cvmccuiywivysddl) |
| 06:05.01 | MonMotha | gkwhc: how long does the overall audio output last compared to how long would be expected? |
| 06:05.27 | MonMotha | big thing to consider about MP3 vs. WAV (for the same sample rate/bit depth) is that the WAV (or any raw audio format) will require a lot more bandwidth from the storage medium |
| 06:22.29 | gkwhc | MonMotha: bandwidth, as in CPU time? to me it seems like raw audio format will consume less bandwidth since they dont require decoding. the only operation i performed was read in 2 channels of 512 words (16bit samples), using the original system of 3 buffers of 1024 words |
| 06:23.31 | gkwhc | well, I also did byte swapping (since the DSP is big endian) and untangled the samples (L/R channels in separate blocks) |
| 06:25.07 | MonMotha | gkwhc: bandwidth as in "clock the bits off the storage medium into RAM and shovel them around with the CPU, if needed" |
| 06:25.41 | MonMotha | in other words, if your SD card can only sustain 500kilobits/sec for whatever reasons (e.g. driver isn't very good), you could easily keep up with a typical MP3 but would totally choke on raw CD quality audio |
| 06:26.19 | MonMotha | also, I don't know how fast your DSP is or much about it, but a naive implementation of a byteswap + interleave/deinterleave could easily take more CPU time than a properly written MP3 decoder |
| 06:26.21 | MonMotha | DSPs are funny like that |
| 06:26.59 | gkwhc | haha that seems rather ironic :p |
| 06:28.32 | gkwhc | i'll check the CPU & SD clock frequency, though i am pretty sure the CPU freq is >50MHz and that its using SD/MMC interface instead of SPI |
| 06:35.15 | *** join/#edev dijenerate (~dijenerat@65.48.221.118) |
| 06:37.07 | MonMotha | a 50MHz CPU can easily have trouble shoveling around the ~1.5Mbps of data that raw CD-quality audio works out to if you're not careful |
| 06:37.43 | MonMotha | for example, when bringing up a system that read such audio off an SD card using a SPI interface, my initial SPI driver was interrupt driven, not DMA (because it was easy), and I burned up basically all the time available on a 96MHz ARM-CM4 with it |
| 06:40.35 | gkwhc | oh wow |
| 06:41.19 | gkwhc | i just checked the CPU freq, turns out to be 40MHz. I'll now check the SD interface |
| 06:43.06 | MonMotha | what type of DSP is this? |
| 06:48.08 | gkwhc | its the C5535 DSP |
| 06:48.16 | gkwhc | from TI |
| 06:49.29 | gkwhc | ah, its using 4bit mode SD interface with 20MHz memory clock |
| 06:49.54 | *** join/#edev bsdfox_ (~h36sa@107-221-62-129.lightspeed.frokca.sbcglobal.net) |
| 06:49.54 | *** join/#edev bsdfox_ (~h36sa@unaffiliated/bsdfox) |
| 06:51.18 | *** join/#edev Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 06:57.20 | MonMotha | those can be a pain to program |
| 06:57.24 | MonMotha | very powerful, don't get me wrong |
| 06:57.35 | gkwhc | <PROTECTED> |
| 06:57.43 | MonMotha | but you have to pay very careful attention to the pipeline structure |
| 06:57.58 | MonMotha | are you sure it's actually 4 cycles? |
| 06:58.10 | MonMotha | if you're writing it in C, it could easily compile to more like 400 |
| 06:58.26 | MonMotha | (it may also compile to 4 - check a disassembly) |
| 06:58.41 | MonMotha | however, you never answered my original question: how long does the overall audio output last compared to how long would be expected? |
| 06:59.15 | gkwhc | oh the sampling rate is correct |
| 06:59.24 | MonMotha | If the output takes the expected amount of time, you probably don't have a bandwidth issue but just rather an audio format issue. If the output is slowed relative to real time (the pitch shift may be masked for other reasons), then you may have a bandwidth issue. |
| 06:59.53 | MonMotha | I'm not trying to imply that your sampling rate is incorrectly configured. If you're underflowing the output, you'll still have it take longer to play, but it'll sound "glitchy" rather than pitch shifted |
| 07:00.32 | gkwhc | wouldnt it sound "longer" as well? as if each note is played longer |
| 07:00.49 | gkwhc | longer/shorter |
| 07:01.05 | MonMotha | not if the sampling rate is configured properly |
| 07:01.30 | MonMotha | when data is available, it would sound correct, but when there's an underflow, it'll do something "bad" (either drop out or replay whatever was in the FIFO, etc.) |
| 07:03.28 | gkwhc | hm that might be a possibility |
| 07:07.19 | gkwhc | altho, the file is specified to play at 44.1KHz, but when I played it at 48KHz it sounded more like the original speed, with added pops. if I played it at 44.1KHz, it sounded slower, but still with the pops |
| 07:14.21 | MonMotha | that would be consistent with underflowing to some degree |
| 07:14.31 | MonMotha | does TI not have a wave player demo? |
| 07:16.08 | gkwhc | no unfortunately. TI doesn't have an abundance of demos. even the examples arent well documented, if at all |
| 07:19.46 | av500 | but ti has a lot of docs around using MsBSP |
| 07:20.14 | av500 | if you want to rule out bandwidth, create a sine wave in memory and play that |
| 07:22.41 | *** join/#edev ntfreak (~ntfreak@unaffiliated/ntfreak) |
| 07:23.35 | gkwhc | oh good idea |
| 07:26.15 | MonMotha | yeah, I've noticed TI's sample code is usually pretty lacking (and bad, when present) |
| 07:26.19 | MonMotha | but the docs are usually pretty good |
| 07:26.26 | MonMotha | caveat: I haven't actually really tried to USE them |
| 07:26.35 | gkwhc | av500: what would it sound like if it were a bandwidth problem? |
| 07:26.35 | *** join/#edev florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
| 07:26.35 | *** join/#edev florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 07:27.31 | gkwhc | MonMotha: agreed. too bad though, they make such powerful products. |
| 07:28.15 | MonMotha | their DSPs are quite nice, though I've not been particularly impressed by their ARM lineup aside from OMAP, which is not generally available for low-volume usage |
| 07:28.23 | MonMotha | the DaVinci is OK at best |
| 07:28.42 | MonMotha | Sitara is nothing special |
| 07:29.47 | av500 | its like all the others |
| 07:29.54 | av500 | ARM, periphery and a fat TRM |
| 07:30.35 | av500 | gkwhc: well, playing a sine wave from RAM would decouple sdcard reading from playback |
| 07:31.03 | gkwhc | ah yes |
| 07:37.06 | MonMotha | av500: indeed, though the quality of said periphery and TRM matters a lot |
| 07:37.17 | MonMotha | I don't have enough experience with Sitara to really comment on said quality, though |
| 07:37.35 | MonMotha | my admittedly limited experience suggests it's OK, but nothing special |
| 07:37.50 | av500 | yes |
| 07:39.57 | MonMotha | I'm a bit bitter right now about peripherals and TRM |
| 07:40.25 | MonMotha | I just spent the past 4-5 hours debugging an obscure timing issue on the Freescale Kinetis I2C controller |
| 07:40.58 | MonMotha | I say obscure mostly because, near as I can tell, it's totally undocumented, not because it doesn't make sense |
| 07:42.02 | MonMotha | and now I get to learn a bit more about git as I try to clear up my local revision history attached to said debugging effort :) |
| 07:43.43 | *** join/#edev dijenerate (~dijenerat@65.48.221.118) |
| 07:43.59 | *** join/#edev icanicant (~klawson@195.88.236.129) |
| 08:01.41 | *** join/#edev bsdfox_ (~h36sa@107-221-62-129.lightspeed.frokca.sbcglobal.net) |
| 08:01.42 | *** join/#edev bsdfox_ (~h36sa@unaffiliated/bsdfox) |
| 08:16.00 | *** join/#edev fenrig (55eac3e5@gateway/web/freenode/ip.85.234.195.229) |
| 08:48.24 | *** join/#edev calculu5 (~calculus@gentoo/user/calculus) |
| 09:07.10 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 09:12.09 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 09:16.45 | *** join/#edev ffio_ (~fire@unaffiliated/security) |
| 09:33.06 | *** join/#edev m4t (~matt@2604:180::34ea:9d4b) |
| 09:39.54 | *** join/#edev jackmitchell (~Thunderbi@host217-34-104-101.in-addr.btopenworld.com) |
| 09:58.54 | *** join/#edev jackmitchell (~Thunderbi@host217-34-104-101.in-addr.btopenworld.com) |
| 11:20.13 | *** join/#edev g1powermac (~g1powerma@rrcs-74-87-150-6.west.biz.rr.com) |
| 11:20.13 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 12:14.36 | *** join/#edev Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 12:58.46 | *** join/#edev damkerngt (~Administr@27.130.45.99) |
| 14:06.23 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 14:16.02 | *** join/#edev espiral (~maze@unaffiliated/espiral) |
| 14:29.31 | *** join/#edev dgerlach (~a0274052@192.94.92.11) |
| 15:32.43 | *** join/#edev prpplague (~danders@adsl-68-88-79-206.dsl.rcsntx.swbell.net) |
| 15:34.59 | *** join/#edev icanicant (~klawson@195.88.236.129) |
| 15:44.18 | *** join/#edev ffio (~fire@unaffiliated/security) |
| 15:53.34 | *** join/#edev Crofton|work (~balister@pool-108-44-80-43.ronkva.east.verizon.net) |
| 15:59.47 | *** join/#edev Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 16:21.40 | *** join/#edev g1powermac (~g1powerma@rrcs-74-87-150-6.west.biz.rr.com) |
| 16:21.41 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 16:25.01 | *** join/#edev groglogic (~groglogic@ip-64-134-157-206.public.wayport.net) |
| 16:34.50 | *** join/#edev bsdfox_ (~h36sa@107-221-62-129.lightspeed.frokca.sbcglobal.net) |
| 16:34.50 | *** join/#edev bsdfox_ (~h36sa@unaffiliated/bsdfox) |
| 16:49.38 | *** join/#edev g1powermac_ (~g1powerma@rrcs-74-87-150-6.west.biz.rr.com) |
| 16:58.24 | *** join/#edev damkerngt (~Administr@27.130.45.99) |
| 16:59.21 | *** join/#edev Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 17:00.53 | *** join/#edev groglogi_ (~groglogic@ip-64-134-157-206.public.wayport.net) |
| 17:04.04 | *** join/#edev espiral (~maze@unaffiliated/espiral) |
| 17:06.33 | *** join/#edev Crofton (~balister@96.sub-75-197-30.myvzw.com) |
| 17:11.45 | *** join/#edev Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 17:17.02 | *** join/#edev ffio_ (~fire@unaffiliated/security) |
| 17:47.29 | *** join/#edev bsdfox (~h36sa@unaffiliated/bsdfox) |
| 17:52.38 | *** join/#edev groglogic (~groglogic@ip-64-134-157-206.public.wayport.net) |
| 18:16.57 | *** join/#edev Crofton (~balister@wsip-98-191-7-58.rn.hr.cox.net) |
| 18:34.05 | *** join/#edev bsdfox\ (~h36sa@unaffiliated/bsdfox) |
| 18:52.30 | *** join/#edev NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 19:00.31 | *** join/#edev orbarron (~a0271968@nat/ti/x-diueghxtzaffeqya) |
| 19:26.23 | *** join/#edev Umeaboy (~Umeaboy@213-21-78-12.customer.t3.se) |
| 19:44.43 | *** join/#edev prpplague (~danders@adsl-68-88-78-118.dsl.rcsntx.swbell.net) |
| 19:55.58 | *** join/#edev k-way (~keesj@pc-020965.clients.vu.nl) |
| 20:06.31 | *** join/#edev ChanServ (ChanServ@services.) |
| 20:06.31 | *** mode/#edev [+o ChanServ] by orwell.freenode.net |
| 20:48.55 | *** join/#edev groglogic (~groglogic@ip-64-134-29-197.public.wayport.net) |
| 21:09.42 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 22:00.57 | *** join/#edev gkwhc (d03620a9@gateway/web/freenode/ip.208.54.32.169) |
| 22:03.33 | gkwhc | MonMotha: i finally found the problem! the popping noise was caused by wrong configuration of the RTOS streaming IO |
| 22:04.01 | gkwhc | thanks for all your help :) |
| 22:06.18 | gkwhc | i was also wondering, typically in embedded systems development, should one perfect a module (with specified features) before going on to the next module, or push out a minimum viable system (then make it more efficient, add needed features, etc)? |
| 22:13.26 | MonMotha | are you a waterfall or agile shop? :) |
| 22:14.10 | MonMotha | personally I find agile to be a bit troublesome in embedded development. It's workable, with some caveats, for firmware, but it falls flat on its face for hardware due to the NRE and time-lag associated with a prototype build |
| 22:23.38 | gkwhc | oh true, those are really good points |
| 22:24.19 | gkwhc | dont really understand the waterfall analogy though :p |
| 22:27.18 | gkwhc | *googes |
| 22:35.38 | Umeaboy | Does anyone here know how to add support for a certain embedded board when building a new and custom Uboot? |
| 23:05.19 | SpeedEvil | First - do you have detailed design documents on the board, and all the chips on it - if they are not supported? |
| 23:12.17 | *** join/#edev groglogic (~groglogic@ip-64-134-29-197.public.wayport.net) |
| 23:25.45 | Umeaboy | SpeedEvil: No official design documents that I know of. Let me check. |
| 23:26.43 | SpeedEvil | Or any source-code for an OS for it? |
| 23:30.06 | Umeaboy | Yes. |
| 23:30.09 | Umeaboy | Hold on. |
| 23:31.15 | Umeaboy | SpeedEvil: http://www.lg.com/lgecs.downloadFile.ldwf?OPENSOURCE_FILE_NAME=%5BEurope%5DGP1R_M_PDP_FI_2010.tar.gz&OPENSOURCE_ORIGINAL_NAME=%2FOpCAT00000007%2F%5BEurope%5DGP1R_M_PDP_FI_2010.tar.gz&newOpensource=Y |
| 23:31.17 | Umeaboy | There. |
| 23:32.08 | Umeaboy | I'll go away for a shorter time. I'll be back in like.........50 minutes or so. |
| 23:33.55 | SpeedEvil | In principle, you work out what uboot needs to boot, and then implement it. And no, it's not simple. |
| 23:36.43 | MonMotha | I've found it's often harder to port bootloaders than the Linux kernel |
| 23:37.13 | MonMotha | 1) The bootloader often has to do more (bring up the harder from a "lower" state, handle SoC specific booting quirks, etc.) 2) The bootloader has fewer friendly facilities at your disposal |
| 23:37.20 | MonMotha | s/harder/hardware/ |
| 23:46.11 | *** join/#edev roxfan (dunno@157.186-242-81.adsl-dyn.isp.belgacom.be) |