Whether or not this is correct depends on how the source material was
mastered, digitized, and/or encoded. There is no setting appropriate
for everything.
Eventually I'd like to make this configurable, but I'd want to have it
shared with more than one target first.
Change-Id: I20a0eff4b3dc2517c33db49d4f72e85bf81d1ca6
Note: PCM mix buffer sizes are _way_ too small for these high bitrates
(We really need to make the mixer stuff use dynamic buffer sizes based
on the bitrate. Maybe pre-allocate a max size based on upper bitrate limit,
but use only part of it at lower bitrates? So we can have sane latency..)
Change-Id: Id7b4afd73dba7f1ffb84b2e1c016859fae5d6835
Can be disabled at runtime by setting hold switch.
Boosts sysbench sequential write performance by 34-58%
Change-Id: I060c9d7dddc1b448f18aa46af8f8aff046e07843
* DMA Bulk IN (ie our TX) results in sequential transfers 33-68% faster.
* DMA Bulk OUT (ie RX) is mostly stripped out due to complete brokenness.
* Interrupt and control endpoints remain PIO-driven.
Other improvements:
1) Use consistent endpoint references (no magic numbers)
2) Greatly enhanced logging
3) DMA support can be compiled out completely
4) Setting lockswitch will disable all DMA operations at runtime
5) Much more robust error checking and recovery
Change-Id: I57b82e655e55ced0dfe289e379b0b61d8fe443b4
Fixes deficiencies with the button system on the X3
The x3 has an interesting button layout.
Multiple key presses are NOT supported unless
[BUTTON_POWER] is one of the combined keys
As you can imagine this causes problems as the power button takes
precedence in the button system and initiates a shutdown if the
key is held too long
instead of BUTTON_POWER use BUTTON_PWRALT in combination with other keys
IF using as a prerequsite button then BUTTON_POWER should be used
Multiple buttons are emulated by button_read_device but there are a few
caveats to be aware of:
Button Order Matters!
different keys have different priorities, higher priority keys 'overide'
the lower priority keys
VOLUP[7] VOLDN[6] PREV[5] NEXT[4] PLAY[3] OPTION[2] HOME[1]
There will be no true release or repeat events, the user can let off the
button pressed initially and it will still continue to appear to be
pressed as long as the second key is held
Tree scrolling is PLAY+NEXT or PLAY+PREV
Change-Id: I88dfee1c70a6a99659e8227f5becacc50cc43910
Group commands for a bit more speed
bitdelay was not being inlined
lower bitdelay to 12 cycles
Clean-up magic numbers
Change-Id: Ifeb57a5532807a598f1ec5e1c55f03e4aa1e133f
* Increase audio buffer size to better handle IRQ latency (256->2048)
* Ensure DMA engine is idle prior to starting transfers
* Set AIC to repeat last sample in case of underflows
Change-Id: I9c45c20481ee072e5882b7586fb7d50bd8ef2f35
Based on code originally written by Amaury Pouly (g#1789, g#1791, g#1527)
but rebased and heavily updated.
Change-Id: Ic794abb5e8d89feb4b88fc3abe854270fb28db70
only check button values with adc when buttons are actually pressed
battery level check frequency is now around 30 seconds
switched to polling for the battery voltage w/ timeout
Ifdef functions Allow BACK OPTION PLAY to be the first of a two key combo
Change-Id: Icb48d62ac8d82b4dc931df5e1c5b4a84a9a69772
Back off to 480MHz [max] clock, bus/mem clock of 120MHz.
576 is unstable on at least one unit, and 528 still glitches.
Change-Id: I020e48532524e739f3bfa42bed570381ccd34959
* Don't stop clock before switching speeds
* Don't stop clock prior to transactions
* Stop clock at the end of transactions
Will result in slightly better performance and some power saving when
we're not actively using the SD peripheral.
Change-Id: I1c82476cad97137b1469900645ecf7bb0887119a
* Check to see if clock is [not] running prior to [en|dis]abling it
* Stop clock _prior_ to resetting controller
* Stop clock after transaction is completed, not before initiating it
* Use controller's low power mode (disables clocks when idle)
* Fix, and enable, interrupt-driven DMA transfers
* Fixes for full interrupt-driven operation (WIP, still broken)
Change-Id: I723ffa6450fc85f97898c8a8b3e538ae31c4858e
There's a code path that calls sd_init_device() while we hold sd_mtx, but
sd_init_device() tries to obtain the mutex while doing its work.
Change-Id: I882c595e9e7cd2224b1db0d413925668628476e9
* Allows both SD interfaces to have requests in flight simultaneously
* Fixed a deadlock in the hotswap code
* Ensure TX DMA is idle before initiating a request (bug due to a typo)
Change-Id: I988fa29df5f8e41fc6bbdcc517db89842003b34d
(More specifically, use the SoC's "OS Timer", slaved to the main XTAL so
it doesn't matter how the main CPU is clocked)
Change-Id: I799561ac823ff7f659a05144cf03b6a13d57ea7b
PLL1 clock for those frequencies has been dropped from 508 to 169.5 MHz,
so it's still a respectable reduction.
(I'm not sure how/why it ever worked with the XTAL source, but it did,
and was off by an audible amount)
Change-Id: I614d87e7dfdfe9210702b9c646d3863c06d6780b
