On Thu, Apr 11, 2013 at 12:20:39 -0700, chris hermansen wrote:
First time: I plugged the Schiit USB into the laptop before booting
the laptop (only one altset for output, two for input for stream0)
Second time: I hot-plugged the Schiit USB into the already running
laptop (two altsets for
On Wed, Apr 10, 2013 at 08:46:04 -0700, chris hermansen wrote:
Torstein and list:
Wait! this is still weird. Please see at bottom...
On Wed, Apr 10, 2013 at 8:31 AM, chris hermansen clherman...@gmail.com
wrote:
Torstein, list:
On Wed, Apr 10, 2013 at 2:32 AM, Torstein Hegge
Torstein, list;
On Thu, Apr 11, 2013 at 2:02 AM, Torstein Hegge he...@resisty.net wrote:
[...]
ie no S32_LE altset on either playback or capture. Switching the
Schiit back to USB does not change this.
The USB or S/PDIF input setting on the Schiit shouldn't affect the
behavior of the USB
Torstein and list:
Wait! this is still weird. Please see at bottom...
On Wed, Apr 10, 2013 at 8:31 AM, chris hermansen clherman...@gmail.com wrote:
Torstein, list:
On Wed, Apr 10, 2013 at 2:32 AM, Torstein Hegge he...@resisty.net wrote:
[...]
What does dmesg / /var/log/kern.log say when
On Mon, Apr 08, 2013 at 18:28:30 -0700, chris hermansen wrote:
Torstein and list;
On Mon, Mar 18, 2013 at 12:56 PM, chris hermansen clherman...@gmail.com
wrote:
Torstein and list;
On Mar 18, 2013 12:52 PM, Torstein Hegge he...@resisty.net wrote:
On Sun, Mar 17, 2013 at 07:36:01PM
Torstein, list;
On Tue, Apr 9, 2013 at 12:34 AM, Torstein Hegge he...@resisty.net wrote:
On Mon, Apr 08, 2013 at 18:28:30 -0700, chris hermansen wrote:
[..]
Hmm that was a bit of a slip of the brain. Anyway, I'm actually back
in the same general vicinity as the Bifrost and can do some more
Torstein and list;
On Mon, Mar 18, 2013 at 12:56 PM, chris hermansen clherman...@gmail.com wrote:
Torstein and list;
On Mar 18, 2013 12:52 PM, Torstein Hegge he...@resisty.net wrote:
On Sun, Mar 17, 2013 at 07:36:01PM -0700, chris hermansen wrote:
The kernel's compiled and I'm testing.
On Sun, Mar 17, 2013 at 07:36:01PM -0700, chris hermansen wrote:
The kernel's compiled and I'm testing. Cutting to the chase, I can't
seem to get it to misbehave any more.
I'm a bit worried that you didn't get a single warning about runtime
rate being different from current rate, if this last
Torstein and list;
On Mar 18, 2013 12:52 PM, Torstein Hegge he...@resisty.net wrote:
On Sun, Mar 17, 2013 at 07:36:01PM -0700, chris hermansen wrote:
The kernel's compiled and I'm testing. Cutting to the chase, I can't
seem to get it to misbehave any more.
I'm a bit worried that you
On Thu, Mar 14, 2013 at 10:13:17AM +0100, Torstein Hegge wrote:
If we can find some other explanation for the 'cannot get freq' and the
large negative rate you saw earlier, it might help to replace the
if (cur_rate != prev_rate) {
with
if (rate != prev_rate) {
so that we do the reset if
Torstein and list;
On Sun, Mar 17, 2013 at 5:31 AM, Torstein Hegge he...@resisty.net wrote:
On Thu, Mar 14, 2013 at 10:13:17AM +0100, Torstein Hegge wrote:
If we can find some other explanation for the 'cannot get freq' and the
large negative rate you saw earlier, it might help to replace the
On Wed, Mar 13, 2013 at 09:00:29PM -0700, chris hermansen wrote:
Looking at the messages, I find it odd that the reset doesn't happen
cf. we just jump to the complaint about the rates not matching.
Mar 13 20:33:51 temuko kernel: [ 372.014273] current rate 96000 is
different from the runtime
Torstein and list;
On Tue, Mar 12, 2013 at 1:48 PM, Torstein Hegge he...@resisty.net wrote:
On Tue, Mar 12, 2013 at 07:59:52AM -0700, chris hermansen wrote:
Mar 12 07:13:34 temuko kernel: [ 1221.640038] usb 1-3: new high-speed
USB device number 2 using ehci-pci
Mar 12 07:13:34 temuko kernel:
Torstein and list;
Sorry about the delay with this, life and the garden and what-not kind
of caught up with me over the last few days...
On Sat, Mar 9, 2013 at 12:35 PM, Torstein Hegge he...@resisty.net wrote:
[last experiment's evidence deleted]
According to lsusb -v from
On Fri, Mar 08, 2013 at 08:23:54AM -0800, chris hermansen wrote:
As to the outcome, I have two.
The first is that the problem seems worse now - I get more songs going
into staticky noisy mode.
The second is the attached excerpt of the kernel log file.
Mar 8 08:04:39 temuko kernel: [
Torstein and list;
On Sat, Mar 9, 2013 at 12:00 AM, Torstein Hegge he...@resisty.net wrote:
On Fri, Mar 08, 2013 at 08:23:54AM -0800, chris hermansen wrote:
As to the outcome, I have two.
(blush) (blush) (blush)
What an idiot I am! A new kernel snuck into the updates while I
wasn't paying
On Sat, Mar 09, 2013 at 09:01:48AM -0800, chris hermansen wrote:
I plugged in the Schiit, then with 'sudo aplay -vD
plughw:CARD=Interface,DEV=0' I played:
1. a 44.1/16 for ~ 10 seconds - it sounded fine - so I interrupted it
2. a 96/24 - it was staticky / noisy, even though the plughw slave
Hello Torstein and list;
On Thu, Mar 7, 2013 at 12:30 PM, Torstein Hegge he...@resisty.net wrote:
On Wed, Mar 06, 2013 at 01:15:06PM -0800, chris hermansen wrote:
Does this help?
Kind of, but it doesn't bring me much closer to understanding why this
happens.
It would be nice if I could
On Fri, Mar 08, 2013 at 08:23:54AM -0800, chris hermansen wrote:
As to the outcome, I have two.
The first is that the problem seems worse now - I get more songs going
into staticky noisy mode.
The second is the attached excerpt of the kernel log file.
That looks like the log from plugging
Torstein and list;
On Fri, Mar 8, 2013 at 8:43 AM, Torstein Hegge he...@resisty.net wrote:
On Fri, Mar 08, 2013 at 08:23:54AM -0800, chris hermansen wrote:
As to the outcome, I have two.
The first is that the problem seems worse now - I get more songs going
into staticky noisy mode.
The
On Wed, Mar 06, 2013 at 01:15:06PM -0800, chris hermansen wrote:
Does this help?
Kind of, but it doesn't bring me much closer to understanding why this happens.
It would be nice if I could reproduce this.
This might not be relevant at all, but could you try to do this change on top
of v3 of the
Torstein, list:
On Tue, Mar 5, 2013 at 11:18 PM, Torstein Hegge he...@resisty.net wrote:
On Tue, Mar 05, 2013 at 03:44:04PM -0800, chris hermansen wrote:
On Tue, Mar 5, 2013 at 3:03 PM, chris hermansen clherman...@gmail.com
wrote:
On Mon, Mar 4, 2013 at 6:44 PM, chris hermansen
Torsten and list;
On Mon, Mar 4, 2013 at 6:44 PM, chris hermansen clherman...@gmail.comwrote:
Torstein and list;
On Mon, Mar 4, 2013 at 2:44 PM, Torstein Hegge he...@resisty.net wrote:
On Mon, Mar 04, 2013 at 11:30:03AM -0800, chris hermansen wrote:
I would be happy to test this on my
Torstein and list;
On Tue, Mar 5, 2013 at 3:03 PM, chris hermansen clherman...@gmail.com wrote:
Torsten and list;
On Mon, Mar 4, 2013 at 6:44 PM, chris hermansen clherman...@gmail.com wrote:
Torstein and list;
On Mon, Mar 4, 2013 at 2:44 PM, Torstein Hegge he...@resisty.net wrote:
On
On Tue, Mar 05, 2013 at 03:44:04PM -0800, chris hermansen wrote:
On Tue, Mar 5, 2013 at 3:03 PM, chris hermansen clherman...@gmail.com wrote:
On Mon, Mar 4, 2013 at 6:44 PM, chris hermansen clherman...@gmail.com
wrote:
On Mon, Mar 4, 2013 at 2:44 PM, Torstein Hegge he...@resisty.net wrote:
Gentlemen;
On Sat, Mar 2, 2013 at 4:21 AM, Daniel Mack zon...@gmail.com wrote:
Hi Torstein,
(+ alsa-devel)
On 02.03.2013 12:09, Torstein Hegge wrote:
Daniel Mack zonque at gmail.com writes:
This is a known bug, also most probably flaw in the CMEDIA chip,
and not yet properly worked
On Mon, Mar 04, 2013 at 11:30:03AM -0800, chris hermansen wrote:
I would be happy to test this on my Schiit Bifrost as well. I'm currently
using the TOSLINK connection but it would be easy peasy to hook up a laptop
via the USB.
If you could test the patch i just posted to alsa-devel [1], that
Torstein and list;
On Mon, Mar 4, 2013 at 2:44 PM, Torstein Hegge he...@resisty.net wrote:
On Mon, Mar 04, 2013 at 11:30:03AM -0800, chris hermansen wrote:
I would be happy to test this on my Schiit Bifrost as well. I'm
currently
using the TOSLINK connection but it would be easy peasy to
Daniel Mack zonque at gmail.com writes:
This is a known bug, also most probably flaw in the CMEDIA chip,
and not yet properly worked around in the snd-usb driver. If you
want to investigate, have a look at the feedback format
autodetection code in sound/usb/endpoint.c.
Thanks, I'll
* each
time playback format changes (16/44 to 24/96 and back) the sound is
totally scrambled, but /proc/asound/card2/pcm0p/sub0/hw_params shows
the correct playback format. Stop/start playback solves the problem.
This is a known bug, also most probably flaw in the CMEDIA chip, and not
I've read a quite long discussion here about this USB Audio 2.0 chip.
Apparently there have been problems when switching sample rates.
Now I have bought a cheap USB to S/PDIF interface with this chip (search for
CM6631 USB at www.aliexpress.com) and I wonder if it is better supported
now.
On 12.12.2012 00:42, Thorsten Mühlfelder wrote:
The system is running Slackware 14.0 with kernel 3.2.29 (Alsa
1.0.24).
This kernel is *way* too old. Please try a 3.7 which has just been
released.
OK, I've updated to 3.7.0.
Now lsusb.py shows the device in high speed: 3-3
Problems left:
* There is a blob at the beginning of playback
This is most probably a bug in the hardware chain somewhere. Can you
exclude the possibilty that this plop is produced by the receiving side
and occurs every time the link was lost? You can try that by re-plugging
the optical
On 12.12.2012 22:20, Thorsten Mühlfelder wrote:
Problems left: * There is a blob at the beginning of playback
This is most probably a bug in the hardware chain somewhere. Can
you exclude the possibilty that this plop is produced by the
receiving side and occurs every time the link was
Yes, the discussion has ended without real solution. So this is why I've
asked here again.
As soon as the China device arrives I can test if it has the same issues like
your Schiit.
OK, device has arrived:
lsusb:
Bus 007 Device 003: ID 0d8c:0309 C-Media Electronics, Inc.
lsusb.py:
7-3
On 11.12.2012 20:40, Thorsten Mühlfelder wrote:
Yes, the discussion has ended without real solution. So this is why I've
asked here again.
As soon as the China device arrives I can test if it has the same issues
like your Schiit.
OK, device has arrived:
lsusb:
Bus 007 Device 003: ID
Thorsten, list:
On Tue, Dec 11, 2012 at 4:40 PM, Thorsten Mühlfelder
thenk...@salixos.org wrote:
Yes, the discussion has ended without real solution. So this is why I've
asked here again.
As soon as the China device arrives I can test if it has the same issues
like your Schiit.
OK, device
Daniel, Thorsten, list:
On Tue, Dec 11, 2012 at 4:51 PM, Daniel Mack zon...@gmail.com wrote:
On 11.12.2012 20:40, Thorsten Mühlfelder wrote:
depth 32 bit as suggested). The system is running Slackware 14.0 with
kernel 3.2.29 (Alsa 1.0.24).
This kernel is *way* too old. Please try a 3.7
Try to work with aplay -v and you should get immediate feedback
without having to check files etc. If I recall aplay -v -D hw:2,0
with a 96/24 file should tell you that 24 bits is not supported and
suggest some others that are.
Yes, aplay tells me:
Available formats:
- S16_LE
- S32_LE
But
The system is running Slackware 14.0 with
kernel 3.2.29 (Alsa 1.0.24).
This kernel is *way* too old. Please try a 3.7 which has just been released.
OK, I've updated to 3.7.0.
Now lsusb.py shows the device in high speed:
3-30d8c:0309 ef 2.00 480MBit/s 100mA 3IFs (CMEDIA
I guess I was the last person discussing the use of this chip, in the
Schiit Bifrost
http://schiit.com/cart/index.php?main_page=product_infocPath=0products_id=7
Yes, it was your discussion about the Schiit.
The second is that hw does not handle the 24 bit word length, at
least in this
Thorsten and list;
The second is that hw does not handle the 24 bit word length, at
least in this context, necessitating the use of plughw to get to 32
bits.
Thanks for the information. So I need something like this?
pcm.usbplug {
type plug
slave {
pcm
42 matches
Mail list logo
