Recent content by bsp

  1. bsp

    Pandora Open Pandora Super Low Latency Audio (mini howto)

    The change in omap-pcm.c does not seem necessary. Actually it seems to break sth -- I upgraded to the latest kernel (3.2.61) today, applied the patch, and then noticed 'spurious IRQ' messages in the klog when trying to record audio in Audacity. Reverting that file to the original made those...
  2. bsp

    Pandora Open Pandora Super Low Latency Audio (mini howto)

    is this something for the firmware kernel?  ==> yes btw which audio software are you using?? ==> my own (work in progress)
  3. bsp

    Pandora Open Pandora Super Low Latency Audio (mini howto)

    Just want to swing by for a second to tell you how happy I am with my Pandora right now :-) I spent the whole day figuring out how to configure it for realtime MIDI and audio. This morning it was a crackle / glitch-fest.. ..now I have a stable, zero underrun, 1.4ms (!) low latency audio...
  4. bsp

    [announce] c64_tools (DSP loader and IPC)

    hmm... that's quite terrible indeed (more than 10x slower than on the Pandora!) the RPC_ADD_BENCHMARK uses the DSP polling mode which calls pthread_yield() each third loop iteration (in src/linux/osal/osal_linux.c:osal_yield(). You could try commenting out that line, for testing purposes. You...
  5. bsp

    [announce] c64_tools (DSP loader and IPC)

    @cloudef: First of all: I have not benchmarked the vertex shader performance of the SGX533 but I would assume that the vertex processor is not highly parallel and processing is rather sequential. There is not any dedicated VRAM to hold vertex buffers so constantly updating the vertices via CPU...
  6. bsp

    [announce] c64_tools (DSP loader and IPC)

    You have to allocate physically contiguous shared memory, just take a look at one of the testcases in c64_tc.c (look for dsp_shm_*). It's almost as easy as using malloc/free. Actually, you just need two extra calls to setup a shared memory heap (dsp_shm_alloc() and dsp_mspace_create()), then...
  7. bsp

    [announce] c64_tools (DSP loader and IPC)

    @Letalis Sonus: Sounds like every major player has its own API then, Intel=VA-API, AMD=XvBA, NVidia=VDPAU, Imagination=also VA-API?, TI/OMAP=?  Anyway, I don't have much hope for proper video acceleration on OMAP3. Hasn't happened in 5 years so why should it now. Hopefully this will be different...
  8. bsp

    [announce] c64_tools (DSP loader and IPC)

    Looks like you can compile the source w/o X86 assembly optimizations so I would say yes, you can run that. Question is whether it will, without further optimizations, run faster than a Cortex-A8 build of it (..probably not). Making the decoder use the OMAP h264 video acceleration HW could...
  9. bsp

    Running scalers on DSP

    @M-HT: Thanks for reporting the typo. I didn't notice since the test only transfers a few bytes so there's probably not much to wait for. Your test results regarding linked transfers are quite interesting. Originally I added them since I had a usecase where I needed to gather more memory...
  10. bsp

    [announce] c64_tools (DSP loader and IPC)

    @Levi and the-user-formerly-known-as-WizardStan: The OMAP5 DSP is heavily stripped down: Only 4 execution units instead of 8, no software pipelined loops, L1 and L2 SRAM cannot be used as flat memory. I really don't understand TI's decision to cripple it that way. However, any...
  11. bsp

    [announce] c64_tools (DSP loader and IPC)

    So far we have DSP acceleration routines for Sprites (8x8 or 32x32 in 32bit), featuring alphatest / premultiplied and non-premultiplied srcover blend modes (about twice as fast as SGX hardware graphics accelerator) Planar to chunky graphics conversion (up to 8 Amiga style bitplanes with scroll...
  12. bsp

    [announce] c64_tools (DSP loader and IPC)

    Well, in this case, the credit has to be attributed to some unnamed TI devs from india, who most likely have been sweating about this issue for some time before coming up with the proper (workaround) code :) thanks guys!
  13. bsp

    [announce] c64_tools (DSP loader and IPC)

    Woohoo! Yeah, it's a monster, all right. I thought that even though we don't have direct TI support and there are (apparently) no erratas, they do release at least some of their code as open source, incorporating all the company internal erratas..,  and that's even better than some field...
  14. bsp

    [announce] c64_tools (DSP loader and IPC)

    "notaz and rohezal like this" *g* notaz, does that mean that this is finally working ? (the stresstest's been doing fine so far for ~3h on my 'Ghz' Pandora)
  15. bsp

    [announce] c64_tools (DSP loader and IPC)

    I think I have some good news (for a change). I just transcribed the power on/off functions from SysLink (omap3530pwr.c) to c64_tools. This resulted in the following improvements: udelay() call at the begining of dsp_poweroff() is no longer needed, even if the DSP is powercycled as fast as...
Back
Top