| drmacro | I see a few familiar names here so this is a repost for some from the mailing list. I did an upgrade from 18.04 to 19.04 on my system76 laptop. Onboard sound worked before, now not. BUt, if I boot from a live usb stick (fresh download of UBS19.04) it does work. alsa-info notes that live is using k5.0.0-13-lowlatency, upgraded using k5.0.0-16-lowlatency. Anyone else see issues? Any ideas how I can fix it? | 14:16 |
|---|---|---|
| Eickmeyer | TJ-: This one might be up your alley. ^ | 14:39 |
| TJ- | :D That was a one-off for me :p | 14:41 |
| Eickmeyer | TJ-: Ah, nm then. :( | 14:41 |
| Eickmeyer | !sound | drmacro, try these steps | 14:42 |
| ubottu | drmacro, try these steps: If you're having problems with sound, click the Volume applet, then Sound Preferences, and check your Volume, Hardware, Input, and Output settings. If that fails, see https://help.ubuntu.com/community/Sound - https://help.ubuntu.com/community/SoundTroubleshooting - https://alsa.opensrc.org/DmixPlugin - For playing audio files, see !players and !mp3. | 14:42 |
| Eickmeyer | And, unfortunately, that's all I've got. We've already tried opening ubuntustudio-controls and clicking "Stop Jack". | 14:43 |
| TJ- | "aplay -l/-L" are the first port of call check the PCH device is working, and default, plus "amixer -c X" to check the sound levels/mute status of the device | 14:44 |
| TJ- | *assuming PCH built-in is the desired output device, and not something else | 14:44 |
| TJ- | and of course the trusty "speaker-test -D front:PCH -c 2 -t wav -l 2" | 14:48 |
| Eickmeyer | drmacro: ^ | 14:49 |
| drmacro | Bin there done that. works fine on the live 19.04, not on the installed 19.04. The PCH device IS there on the live, not on the installed. Why does/would the live use an older kernel than the installed? | 15:00 |
| OvenWerks | drmacro: the iso is static from release. For an LTS 4 for maybe 5 "point" releases are made as well so there is less updating after install. 19.04 is not an lts and so only lasts for 18 mo (i think) and has no point releases. | 15:09 |
| OvenWerks | If an install has been made from the iso and up dated, the original kernel should still be available for booting from. Hold down shift after the MB boot screen to get the grub menu. | 15:13 |
| OvenWerks | (if you already have more than one partition it will show up with no shift anyway) | 15:13 |
| OvenWerks | Having looked at the links above, I see one of the mosre useful commands is not shown... | 15:17 |
| drmacro | OvenWerks: So the installed was 18.04. Then do-release-upgrade to 18.10, then do-release-upgrade to 19.04. Grub menu has one low-latency and only one other (I guess it is non-lowlatency?) | 15:17 |
| OvenWerks | cd /tmp && wget http://jackaudio.org/downloads/adevices.sh && bash ./adevices.sh | 15:17 |
| OvenWerks | drmacro: in that case they would both be the same. | 15:18 |
| OvenWerks | if you want to use an older kernel it is still possible. I would use synaptic, but command line is also possible. | 15:19 |
| OvenWerks | As I am using 18.04 rather than 19.04, mine will show different. | 15:20 |
| OvenWerks | but I show the original version and the updates version | 15:21 |
| drmacro | OveWerks: sorry, ya lost me. Why do I want to use adevices.sh? I've never changed kernel, command line or with synaptic | 15:21 |
| OvenWerks | I can use force version to install thge older version. | 15:21 |
| OvenWerks | that command (the whole line) gives the best list of what devices you have how they are laid out, etc. | 15:22 |
| OvenWerks | drmacro: Eickmeyer added another command on the end to automatically paste the output to a paste site. | 15:23 |
| OvenWerks | There are some motherboards where the hdmi devices are not a part of the PCH device and are detected first... making them the default. | 15:24 |
| OvenWerks | I don't, off the top of my head, know what your setup is or what you are trying to do with that setup. | 15:25 |
| drmacro | I ran that and it's similar to the alsa-info output I got that showed the kernel differences. Playback device 0 is the onboard analog. But it does not show up in paucontrol. It did on 18.04, does on live 19.04, but not on upgraded 19.04 | 15:25 |
| OvenWerks | pavucontrol in the configuration tab? | 15:26 |
| OvenWerks | Still I would like to see a paste for the above command. | 15:28 |
| drmacro | Where do you want it pasted? | 15:28 |
| OvenWerks | pastebin or some such | 15:29 |
| OvenWerks | if you add |pastbinit to the end of that command it should work. | 15:30 |
| OvenWerks | sorry, spelling mistake pastebinit | 15:30 |
| OvenWerks | forgot the e somehow. | 15:30 |
| drmacro | https://pastebin.com/44f7SjwJ | 15:31 |
| OvenWerks | the device is locked by timidity | 15:31 |
| OvenWerks | pulse can acces it | 15:31 |
| OvenWerks | I would sugest to unistall timidity | 15:32 |
| drmacro | one other note: the upgraded 19.04 will play through the HDMI devices listed in the output | 15:32 |
| OvenWerks | yup that is the only device left | 15:32 |
| drmacro | Where did timidy come from...I didn't do it. :P | 15:33 |
| OvenWerks | I don't know, I am pretty sure Studio does not ask for that. It may have been added as a dependency to something | 15:33 |
| OvenWerks | it may be the timidity-daemon package that is at fault | 15:35 |
| OvenWerks | it is not installed in 18.04 | 15:36 |
| drmacro | hmm...apt shows timidity/disco installed | 15:37 |
| OvenWerks | I wonder if there is a way of turning it off | 15:37 |
| drmacro | and the apps shows a timidi sequencer... | 15:38 |
| OvenWerks | it is listed as a dependecy to a lot of things... one hopes they are not hard dependencies | 15:39 |
| OvenWerks | the actual bianry that has locked your soundcard is just timidity | 15:40 |
| drmacro | Yes, and timidty does show in the process list. | 15:41 |
| OvenWerks | if you try to remove that package, it should show a list of other packages it wants to remove that depend on it. That may give insite as to where it came from. | 15:41 |
| OvenWerks | (PID 1102) | 15:41 |
| drmacro | apt says: The following packages will be REMOVED: | 15:44 |
| drmacro | timidity timidity-interfaces-extra | 15:44 |
| OvenWerks | that is fine then | 15:44 |
| OvenWerks | It should not break anything. | 15:44 |
| OvenWerks | timidity is a utility to make your sound card work like a 1980s sound card with synth built in like the gravis and others | 15:46 |
| drmacro | apt remove, then kill the running timidity, aaaaaaand! onboard sound is back. :-D | 15:48 |
| OvenWerks | great! | 15:48 |
| OvenWerks | now you know why that is my favourit audio check command | 15:48 |
| drmacro | Thank you! Thank you! :) | 15:49 |
| OvenWerks | no problem. | 15:49 |
| drmacro | And how would I have found out about it (or even known how to interpret it) if I didn't come here? | 15:49 |
| OvenWerks | we will look at adding this as a "known problem" to the trouble shooting wiki | 15:51 |
| drmacro | Now I can go back to working on the IoT thingy I was working on in ESP32 land. (A honeydo...) ;-) | 15:51 |
| OvenWerks | enjoy... | 15:51 |
| drmacro | Buy all, and thanks again to all. | 15:51 |
| === sam is now known as Guest72098 | ||
| Thr0r | Hi! I have a strange problem: Laptop-1 Dual boot Ubuntu Studio 19,04/Win7, Laptop-2 Xubuntu only. Download/Upload to internet: Studio download 35, upload 0,8 Mbit/s, Win7 download 49, upload 31 Mbit/s. Xubuntu download 35 upload 20 MBit/s. Makes me think there are some network settings in Studio making it only upload 0,8 MBit/s? And look at the difference Ubuntu/Windows...Huge. This is several tests, same results.. Same Wifi. | 20:19 |
| Eickmeyer | Thr0r: There is literally no difference. We do no tweaking to the wifi or drivers, and the kernel has literally one build flag of difference that wouldn't be enough to do that. Different hardware? | 20:20 |
| Thr0r | Eickmeyer: Studio and Win7 is the same HW/Laptop. Xubuntu is a different laptop/HW | 20:21 |
| Eickmeyer | Thr0r: You're looking for problems. We do no tweaking that would cause that. It has to be a configuration problem on your end. | 20:22 |
| Thr0r | Eickmeyer: I would not know how to configure anything I just recently installed Studio... | 20:23 |
| Thr0r | Eickmeyer: 'Why you say "I looking for problems"? | 20:24 |
| Thr0r | Eickmeyer: was the your final reply? if so - where else can I ask about this? | 20:31 |
| Eickmeyer[m] | Sort, been battling a bad laptop display logic board. Rip. | 20:32 |
| Eickmeyer[m] | I suggest ##networking. I guess I reacted that way because out of thousands of people where it just works, you have come in here comparing it to Windows. Windows has a completely different way of interfacing with your hardware, and most manufacturers target Windows. You might need to tweak the driver somehow, but that’s not an Ubuntu Studio-specific problem. | 20:35 |
| TJ- | Thr0r: #ubuntu - sounds very much like a Wifi driver/firmware issue | 20:35 |
| Eickmeyer[m] | Thr0r ^ | 20:35 |
| TJ- | Thr0r: or we can investigate here where it is quieter | 20:36 |
| * Eickmeyer[m] shouldn't talk on IRC when in a bad mood. Primary computer's display is dead. | 20:37 | |
| Thr0r | TJ-: Ok - Yes please. I was uploading an attachment of 30MB today in gmail using Studio and it took just forever. So if you can help here pleas. | 20:38 |
| Thr0r | Eickmeyer[m]: Ok - good luck | 20:38 |
| TJ- | Thr0r: show us "pastebinit <( uname -r; lspci -nnk; iwconfig; iw list )" | 20:39 |
| Thr0r | TJ-: give me that link to the pastebin page - can't find it | 20:45 |
| TJ- | Thr0r: you type the command literally as I wrote it, can copy/paste it | 20:46 |
| TJ- | Thr0r: "pastebinit" is a command on your system | 20:46 |
| Thr0r | enp2s0 no wireless extensions. | 20:48 |
| Thr0r | lo no wireless extensions. | 20:48 |
| Thr0r | /usr/bin/pastebinit:42: DeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5 | 20:48 |
| Thr0r | release = platform.linux_distribution()[0].lower() | 20:48 |
| Thr0r | /usr/bin/pastebinit:413: DeprecationWarning: pasteURLopener style of invoking requests is deprecated. Use newer urlopen functions/methods | 20:48 |
| Thr0r | url_opener = pasteURLopener() | 20:48 |
| Thr0r | http://paste.ubuntu.com/p/J46XDVrVJR/ | 20:48 |
| TJ- | Thr0r: hmmm, it's not supposed to spout errors! | 20:51 |
| TJ- | Thr0r: so we're dealing with a Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) [168c:002b] | 20:51 |
| TJ- | Thr0r: so it's 2.4GHz only: "AzureWave AW-NB037H 802.11bgn" | 20:52 |
| TJ- | Thr0r: do this: echo "options ath9k nohwcrypt=1" | sudo tee -a /etc/modprobe.d/ath9k.conf | 20:55 |
| Thr0r | TJ-: Ok, Is that no good for ubuntu? | 20:55 |
| TJ- | Thr0r: then do "sudo modprobe -rfv ath9k && sudo modprobe -v ath9k" | 20:55 |
| TJ- | Thr0r: then redo your speed test and you'll likely find it is fixed | 20:56 |
| Thr0r | TJ-: Download is a bit slower and upload is the same.. | 21:01 |
| TJ- | Thr0r: where are you testing to/from ? | 21:01 |
| Thr0r | TJ-: This site : http://www.bredbandskollen.se/ | 21:02 |
| TJ- | Thr0r: let me set up a test receiver on a server of mine so I can see how well your client is doing | 21:04 |
| Thr0r | ok | 21:05 |
| TJ- | hmmm, need to tweak it a bit! | 21:12 |
| Thr0r | TJ-: ok - I'll wait. | 21:12 |
| TJ- | Thr0r: fixed it :) I will set up a monitor for your IP address and watch the throughput. Find a file of about 5MB or more (it gets written to /dev/null so doesn't hang around!) https://iam.tj/projects/test/ | 21:16 |
| TJ- | Thr0r: looks like it stalled for a long time there, then resumed | 21:21 |
| Thr0r | TJ-: ok - Sould I try again? | 21:21 |
| TJ- | Thr0r: no | 21:21 |
| TJ- | Thr0r: you're only sending the one file, is that correct? I'm only looking at one attempt to send? | 21:22 |
| Thr0r | TJ-: yes one file - 5,4MB | 21:22 |
| TJ- | once it's finished we can look at the start/end times and calculate the throughput. I'm already wonderinf if the issue is the MTU/MSS on your client being too large | 21:23 |
| Thr0r | TJ-: is that some network block size or something? | 21:24 |
| TJ- | You client is setting the Don't Fragment flag on packets, and they're 1,500 bytes which is a full Ethernet frame. What kind of connection do you have to your ISP? Is it xDSL, fibre-to-the-home, cable ? | 21:25 |
| Thr0r | TJ-: "There was a problem uploading your file (try a smaller file)." Tour page said now | 21:25 |
| TJ- | Thr0r: ha! probably I forgot the server has an internal limit which probably defaults to 5MB :D | 21:26 |
| Thr0r | TJ-: I think they have set up some kind of fibre here now | 21:26 |
| TJ- | Thr0r: no matter, collected enough data in the log to work with | 21:26 |
| Thr0r | TJ-: ok | 21:27 |
| TJ- | Thr0r: is it a home Internet service, our you're sharing with others, or a business? | 21:27 |
| Thr0r | TJ-: It's at home. Only me. Other apartsments has it's own.. | 21:28 |
| TJ- | Thr0r: looks to have taken 384 seconds, if we assume ~5MB total, that's about 13KB/s | 21:29 |
| TJ- | Thr0r: is that about what you felt it was? | 21:29 |
| Thr0r | TJ-: I don't know - but it took almost 15min to upload 30mb to google disk | 21:31 |
| TJ- | Thr0r: let's collect more information. " pastebinit <( ip link show; journalctl --since="15 minutes ago" ) " | 21:32 |
| TJ- | Thr0r: how does your gateway/router connect to the Internet? this is important to know. does it have an ethernet cable connected to its WAN port, or a xDSL connection to a telephone socket? | 21:34 |
| Thr0r | TJ-: no telephone socket. I think it goes to the fibre box - let me check | 21:39 |
| M_aD | Eickmeyer[m]: ouch, bummer :( | 21:40 |
| Thr0r | TJ-: ethernet cable and I think it goes to the fibre box in the hall | 21:40 |
| TJ- | Thr0r: OK, so there's no obvious place for a bottleneck on the wired side. | 21:41 |
| TJ- | Thr0r: there are a lot of known issues with the ath9k based devices - it's finding out which particular solution will solve your problem that is the challenge. | 21:42 |
| Thr0r | TJ-: No - and it works fine on Xubuntu on another computer and on windows on the same as Studio computer | 21:42 |
| TJ- | Thr0r: did you miss my request for more info? | 21:45 |
| TJ- | 22:32 <TJ-> Thr0r: let's collect more information. " pastebinit <( ip link show; journalctl --since="15 minutes ago" ) " | 21:45 |
| Thr0r | http://paste.ubuntu.com/p/SZnN7Kcp6G/ | 21:45 |
| TJ- | Thr0r: hmmmm "mode DORMANT" doesn't look correct | 21:48 |
| TJ- | Thr0r: oh, apparently that is fine and expected. Never noticed that before | 21:48 |
| Thr0r | TJ-: ok. Is that Ubuntu settings or is that straight from the network card info? | 21:49 |
| TJ- | Thr0r: not settings; there are none, there's some interaction on the wifi device that is causing this | 21:50 |
| TJ- | Thr0r: I need to see the entire kernel boot log in case there are clues during boot. "pastebinit <( dmesg )" | 21:50 |
| TJ- | Thr0r: are you using Bluetooth devices on the PC as well? | 21:52 |
| Thr0r | http://paste.ubuntu.com/p/D7zhwqSnDq/ | 21:53 |
| Thr0r | TJ-: No - I'm not using that. | 21:54 |
| TJ- | Thr0r: whilst I read the log do another speed test after issuing this command: "sudo ip link set dev wlp3s0 mtu 1450" | 21:56 |
| Thr0r | TJ-: ok - on your testpage or the one I used before? | 21:57 |
| TJ- | Thr0r: on your regular speedtest page that shows you the speeds | 21:59 |
| TJ- | Thr0r: there's a big clue in the kernel log. The device is missing handling interrupts. "ieee80211 phy0: Atheros AR9285 Rev:2 mem=0xffff9d3742690000, irq=17" ... "irq 17: nobody cared" ... "[<0000000014706360>] irq_default_primary_handler threaded [<00000000c395e9cf>] ath_isr [ath9k]" | 22:00 |
| Thr0r | TJ-: Ok. The latests test since the first change you gave me has resulted slower downloads. From the 35 it is now between 24 and 30.. | 22:01 |
| Thr0r | TJ-: uploads are the same as before | 22:03 |
| TJ- | Thr0r: OK, that makes sense since we reduced the size of packetes | 22:05 |
| TJ- | Thr0r: you can set that back with "sudo ip link set dev wlp3s0 mtu 1500" | 22:05 |
| TJ- | Thr0r: and try flipping the hwcrypt setting in the driver too, with "sudo modprobe -r ath9k && sudo modprobe ath9k nohwcrypt=0" | 22:06 |
| TJ- | Thr0r: I've found an old bug for an older kernel where the ath9k suffers the exact issue you are seeing, and the IRQ handling problem, but that looks like it was solved so could have come back. I'm going to look at the recent changes to the ath9k in the kernel version you've got there | 22:10 |
| TJ- | This is the report(s) I'm referring to https://dev.archive.openwrt.org/ticket/18483.html | 22:11 |
| Thr0r | TJ-: Now it's 47 in downloading and 37 in uploading! :) | 22:11 |
| TJ- | Thr0r: whaaaaaaaaaat? | 22:11 |
| Thr0r | TJ-: after those two last commands | 22:12 |
| TJ- | Thr0r: we best check what state the module is in to be sure why | 22:12 |
| Thr0r | TJ-: What was that last command doing? | 22:12 |
| Thr0r | TJ-: modprobe | 22:12 |
| TJ- | well in *theory* it put the nohwcrypt setting back to what it was before we begain changing things | 22:13 |
| TJ- | Thr0r: show me "pastebinit <( grep . /sys/class/net/wlp3s0/device/driver/module/parameters/* )" | 22:13 |
| Thr0r | http://paste.ubuntu.com/p/x37HX8RN4x/ | 22:14 |
| TJ- | Thr0r: we wrote a config file that sets nohwcrypt=1 so we need to ensure we now change that to =0 (which matches the report you just pasted) | 22:15 |
| TJ- | Thr0r: " sudo sed -i 's/\(nohwcrypt=\)1/\10/' /etc/modprobe.d/ath9k.conf ; cat /etc/modprobe.d/ath9k.conf " ... you should see "options ath9k nohwcrypt=0" | 22:16 |
| TJ- | Thr0r: what we've done may not have fixed it; it *may* be we've just kicked the hardware into not failing on handling interrupt requests for a while... you'll only know by giving it a few days and seeing how it behaves | 22:17 |
| Thr0r | options ath9k nohwcrypt=0 | 22:17 |
| Thr0r | TJ-: Hmm ok. So I can run those commands if it gets slow again? Those Modprobe 1/0 ? | 22:19 |
| TJ- | Thr0r: I don't know if that'd help; it could just be unloading and reloading the module is poking it | 22:20 |
| TJ- | when module (re)loads it resets the hardware which may clear error conditions | 22:21 |
| Thr0r | TJ-: Ok, So I can aleast try them? But no permanent fix for this I understand - and this is just MY type of computer that is having this issue? | 22:22 |
| TJ- | It looks to be that particular wifi adaptaer, yes, and doing 'modprobe -r ... modprobe ...' is a quick fix if it is reliable | 22:24 |
| TJ- | Thr0r: I've looked at the changes in the source-code since v5.0 and there aren't any bug-fixes so it doesn't seem like there's a known regression at present | 22:25 |
| Thr0r | TJ-: Ok, But this has nothing to do with Ubuntu and setting etc. then? Just fauwlty adapter? | 22:27 |
| TJ- | IT seems so; presumably the Windows driver 'knows' about this kind of issue and configures the adapter to avoid it | 22:28 |
| TJ- | we see this all the time, where Windows drivers get all the workarounds from the makers but they don't even inform Linux devs about the workarounds so we suffer | 22:29 |
| Thr0r | TJ-: ok - understand. Maybe that's why this Eickmeyer: was a bit grumpy at me at start here... | 22:30 |
| TJ- | Thr0r: hehehe he's mad at his dead monitor | 22:31 |
| Eickmeyer | ^This. | 22:32 |
| Thr0r | TJ-: ok. I'm just glad it works - and I tested the 30mb upload to google disk aswell so it works fine just now - thanks a million TJ-: :) | 22:32 |
| Eickmeyer | Thr0r: Seriously, I didn't mean to take it out on you. But, yes, the fact that windows drivers get workarounds that the Linux kernel does not is rather frustrating. | 22:33 |
| Eickmeyer | And, I don't even know where to start investigating stuff like that. TJ- has been at it longer than I have. | 22:33 |
| TJ- | Thr0r: glad we got sorted so easily | 22:33 |
| Thr0r | Eickmeyer: That's ok. I was not aware of that so I just asked here. | 22:33 |
| * TJ- dreams of 30Mbps | 22:36 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!